Producing value in a block
Exalynt's standard is excellence, and excellence is a practice, not perfection. This page explains what that means for how you spend a block of Engineering Capacity: how to create value for the client, why it matters to the business, and what to do with the time that remains.
Why value is how Exalynt works
Clients buy capacity one block at a time, with no retainer and no lock-in (see Sharing risk).
- Client buys a blockThe block, not the hours, is the commitment.
- Confirm the goalIn the client's language, not technical terms.
- BuildGet something working early, then improve it.
- CheckpointOutcomes and what we learned. Never hours.
That means:
- Every iteration is where the client decides again. Revenue follows value the client has seen, not a long-term contract.
- The client pays the same no matter how long the work takes. Exalynt absorbs the overrun when work runs long, and keeps the benefit when experience makes it fast. Using time well is part of the job.
- We usually operate what we build. On Exalynt Managed we run production for a flat monthly fee, so fragile software turns into unpaid operational work for us.
- Rework uses up the client's future capacity. A bug shipped today gets fixed with a block the client pays for later.
- Quality is how we keep clients. Clients can leave at any time and take their code and data with them. They stay because the work is good.
Your payout for a block is fixed before you start (details), and it doesn't change with how many hours you spend. What value changes is whether clients keep buying blocks, and that decides how much work there is for everyone.
How to produce value in a block
1. Understand the problem first
The best code is not the point. A well-designed system that solves the wrong problem is still the wrong system. Before building, make sure you can answer:
- Who are we helping, and what are they actually trying to accomplish?
- Which constraints actually matter?
- Should software solve this at all?
- What is the simplest responsible solution?
"Don't build it" is a successful outcome. If a Flex block shows that an existing tool solves the problem, the client has saved money and we have earned their trust.
2. Iterate fast and finish with something real
A block usually lasts one week, occasionally two. Plan backward from the Checkpoint:
- Pick the most valuable slice that can be meaningfully finished in this block, not the most interesting one.
- Get something working early, then improve it. Don't leave integration to the last day.
- End every block with something the client can see, such as a working feature, a deployed improvement, a validated design, a clear recommendation, or an honest write-up of what we learned and what to do next.
- Stay inside the purchased capacity. If more is worth doing, it belongs in the next block, agreed with the client.
3. Communicate clearly and early
- Confirm the goal at the start of the block, in the client's language, not in technical terms.
- Raise risks as soon as you see them. Short iterations exist so a wrong direction shows up in days, not months. Don't save bad news for the checkpoint.
- At the checkpoint, talk about outcomes: what changed, what we learned, what we recommend next, and which block size fits that work.
- Don't report hours to clients. They bought a block, not a timesheet.
4. Use the hours wisely
Each block has a Reference range. It describes scale, not purchased hours: the ranges are not purchased, guaranteed, or tracked, and clients never see a timesheet. Engineers still need a shared sense of how much effort a block deserves. Dedicate at least the minimum to every block, then use the rest of the range as the work requires.
| Block | Reference range | Relative size | Minimum to dedicate | Iteration length |
|---|---|---|---|---|
| Flex | ~1–5 hours | 1× (baseline) | 1 hour | Usually within a week |
| Core | ~10–20 hours | ~4–5× a Flex | 10 hours | Usually one week |
| Dedicated | ~30–40 hours | ~2–3× a Core | 30 hours | One week, sometimes two |
Spend the minimum on direct value for the client. That is the core deliverable: the feature, investigation, fix, or recommendation the block was bought for.
Then use the remaining time based on the project:
- If the work is hard, use the rest of the range to finish it properly. Investigation, experimentation, and debugging are part of the work, and Exalynt absorbs that variance by design. Don't cut corners to hit a number.
- If the value came easily, don't stop at the minimum. Invest the remaining time in things that make this and future blocks better:
- Lift others. Pair with, review, or mentor less experienced engineers on the project.
- Refactor the code you touched so the next block moves faster.
- Ensure quality. Add tests, monitoring, and documentation, and harden edge cases.
- Pay down risk you noticed along the way, such as security, performance, or operational gaps.
- Improve how we work with reusable tooling or shared practices that help every engagement.
Your pay stays the same either way. The minimum sets a floor for what the client receives. The remaining time is where quality, the next engineer, and the next block benefit.
If a block regularly needs far more than its range, the client likely needs a larger block or smaller iterations. Raise this at the checkpoint. It's a sizing conversation, not a failure.
- Never exceed the purchased capacity without the client's agreement. If more work is worth doing, it belongs in the next block.
- Do not report hours to clients as though they were billed. Talk about outcomes and what we learned.
Frequently asked questions
If I finish a Core block's work early, is the block done?
No. Dedicate at least the 10 hours minimum, then use the remaining time on quality, refactoring, or helping other engineers. See Use the hours wisely.
What if the work is going to take far longer than the block's range?
Deliver the most valuable complete slice you can within the iteration, then explain at the checkpoint what remains and what it would take. Do not quietly extend past the purchased capacity.
Does the Managed monthly fee pay for bug fixes and new features?
No. It covers operating production: deployments, monitoring, backups, patching, scaling, and incident response. Changing what the software does uses Engineering Capacity, which is why quality matters.