Creating project estimates
Clients reasonably want to know roughly what a project involves before they start. This page is the lightweight, repeatable way Exalynt engineers build and communicate an Estimate, so every client gets the same shape, the same vocabulary, and an honest range. Project estimates is what the client reads about the result.
Estimation is an exercise in engineering judgment, not a formula that can eliminate uncertainty.
The sizing model gives estimates consistency. Your experience and judgment decide the sizes.
Every estimate ends as Low, Mid, and High: what the project would cost and how many weeks it would take on each of Flex, Core, and Dedicated. It is your best professional judgment from what is known today, not a fixed price, a promise, or a delivery date. Say so when you present it.
The vocabulary
| Term | What it is | Example |
|---|---|---|
| Project | A group of related work that together produces a broader client outcome. | Replace phone-and-spreadsheet scheduling with an online portal. |
| Focus | A piece of the work, whatever it is: a new Feature, or an improvement or enhancement to an existing system. | Technician Dispatch: dispatchers assign technicians to appointments. |
| Notes | Anything else worth saying about a Focus or the project: a boundary, an Assumption, what the size rests on. | Assumes existing Clerk organizations will be used for client tenancy. |
| T-shirt size | Your coarse judgment of a Focus's capacity and uncertainty: S, M, L, or XL. | Technician Dispatch: L |
| Capacity unit | Exalynt's normalized unit of engineering capacity, the same unit blocks are measured in. | Dedicated is 4 units |
Capacity units let you size a Focus without deciding which blocks will deliver it: Flex is 1 unit, Core is 2 units, and Dedicated is 4 units. Capacity units are not hours. Blocks carry an effort reference in hours to describe their scale, but estimates are sized in units only.
An estimate never shows the units. You don't plan a Focus at a block. The estimate shows every Focus, and the project, on every block: what it would cost and how many weeks it would take buying one block of that type a week. The client sees what each choice would mean without being asked to choose up front.
The process
Keep it proportionate. The goal is a useful planning range, not a specification.
Make estimates in the console, including live with a client. Add Focuses, write their descriptions and notes, and pick a size for each. The console works out the rest: each Focus's and the project's cost and weeks on every block. Clients read the estimate in their portal and can download it as a PDF.
- Understand the project outcome. Who is it for, what are they trying to accomplish, and what does success look like, in the client's language? The questions in Producing value in a block apply here too.
- Identify the Focuses: the pieces of work, named the way the client would name them. A Focus can be a new Feature, or an improvement to an existing system, such as "Reporting: CSV export and scheduled reports" (Features and Capabilities). Include foundational work the client benefits from, such as sign-in or getting to production.
- Describe each Focus in a sentence or two when its name doesn't say enough. The description is optional.
- Write the notes that matter: the boundaries that show what a Focus includes, and the assumptions that would move the estimate if they turned out false. Notes that apply to the whole project go on the project.
- Size each Focus S, M, L, or XL using your judgment (Sizing a Focus).
- Check the rollup. Each size spans a Low, Mid, and High range of capacity units, the Focuses add up to the project's, and each block prices them and sets the weeks (Rolling up). The console does the arithmetic.
- Review the result. Is any obvious scope missing? Is there uncertainty no Focus or note captures? For a larger estimate, a second engineer's read is a cheap way to catch gaps.
- Present it as an estimate, never a quote. Lead with the project's Low, Mid, and High on each block, then the Focuses and notes behind them.
Writing Focuses and notes
Estimation shouldn't turn into a miniature requirements phase. Detail belongs in the iterations, where it's discovered with the client. Write short statements of behavior the client or system can observe, not implementation tasks.
| Prefer | Instead of |
|---|---|
| Clients can invite members to their organization. | Build an invitation table, POST endpoint, email worker, Clerk integration, React invitation modal, token validation handler, and expiration cleanup process. |
- Keep it short. A Focus gets a name and, if it needs one, a sentence or two of description; each note is a line or two. If a Focus needs a paragraph, it may be more than one piece of work.
- Name the actor: "Customers can…", "Dispatchers can…", "The system sends…".
- No implementation details: database tables, API endpoints, queues, and components are how, not what.
- Use "cannot" to mark a boundary that matters, such as access between organizations.
- Write a note for anything you'd want to know if it turned out false, such as the payment provider, data migration, or access to a client's systems. Start it with "Assumes" so it reads as an assumption.
Sizing a Focus
Each size maps to a fixed range of capacity units, at Low, Mid, and High. It's the mapping the console uses when you pick a size, and the one the API totals every estimate with:
| Size | Capacity units | Often looks like | ||
|---|---|---|---|---|
| Low | Mid | High | ||
| S | 1 | 2 | 3 | Narrow, familiar behavior with few unknowns. |
| M | 3 | 4 | 6 | Clear behavior with some workflow, roles, or states to work through. |
| L | 6 | 8 | 12 | Broad behavior, several roles or states, or an integration with a system Exalynt doesn't control. |
| XL | 12 | 16 | 24 | Large or substantially uncertain. Usually a sign to split it into smaller Focuses. |
These ranges are a starting point. Exalynt will tune them as estimates are compared with the work that followed. They live in src/data/exalynt.ts, so every page updates together.
- Sizes are intentionally coarse. They are not a hidden form of hour estimation. Don't estimate in hours and convert, and don't try to make a size more precise than it is.
- Don't size by counting notes. A few difficult behaviors can need far more capacity than many straightforward ones.
- Weigh both known and unknown complexity. Uncertainty is part of the estimate. A Focus that looks straightforward but has substantial unknowns can reasonably get a larger size until those unknowns are reduced.
- Same size doesn't mean same effort. Two M Focuses will rarely take identical capacity. That's why each size is a range.
- Treat XL as a prompt to split. Split it into separate Focuses if it's more than one piece of work; otherwise estimate it in phases, such as its first behavior now and more later. If it can't be split because too much is unknown, say what would reduce the uncertainty, such as spending an early iteration on discovery.
XL examples
An XL spans 12–24 units (Mid 16), the widest range of any size. It usually means a Focus is more than one piece of work, or carries more unknowns than a size can honestly hold. These fictional examples show what tends to land at XL, and what to do about it:
| XL Focus | Why it's XL | What to do |
|---|---|---|
| Online Payments for a scheduling product: deposits at booking, card payments on completion, refunds, payment history, and syncing payments to the accounting system. | Several jobs in one, money moving through a payment provider, and reconciliation edge cases. | Split it by job: taking a payment, refunds and payment history, and the accounting sync, each sized on its own. |
| Replace a legacy desktop system: move years of customer and job records into the new portal while staff keep working in the old system. | A data migration of unknown quality, a system Exalynt doesn't control, and two systems running side by side. | Reduce the unknowns first: a small discovery Focus to inspect the data and the old system, then size the migration from what it finds. |
| Patient portal for a clinic: patients book appointments, message the clinic, and see their visit history, with single sign-on, role-based access, and audit logging. | Several roles, personal health data, and privacy and audit requirements running through all of it. | Split it by job (booking, messaging, visit history), and write the privacy and audit requirements as notes on each, so every size weighs them. |
| Two-way order sync with a partner's undocumented API. | Most of the size is unknowns: how the API behaves, its limits, and how its errors surface. | Keep it XL if it's one job, note what's unknown, and propose an early iteration that proves the sync end to end. Re-estimate once it has. |
An XL that stays XL is fine when it's genuinely one piece of work. Say why in its notes, and what would narrow the range.
What can increase a size or widen the range
| Area | Factors |
|---|---|
| Scope | Broader or less clearly bounded behavior. More behavior. Significant edge cases. |
| Behavior | Multiple user roles or permission models. Complex workflows, states, approvals, or branching. Complex or highly interactive user interfaces. |
| Background work | Queues, scheduled work, notifications, or webhooks. |
| Data | Complex data relationships. Data migration. |
| Systems outside our control | External integrations and third-party APIs. Systems Exalynt doesn't control. Legacy system constraints. |
| Quality requirements | Security, privacy, auditing, or compliance. Performance, scale, availability, or reliability. |
| Unknowns | Unfamiliar technologies or domains. Unknown technical constraints. Important assumptions that haven't been validated. |
| Dependencies | Client decisions, access, data, vendors, or other teams. |
Rolling up to a project estimate
A project's Low, Mid, and High are the sums of its Focuses' Lows, Mids, and Highs in capacity units. Each block then turns those units into a cost and weeks:
- Cost: the units at the block's price per unit, its price spread over its units. Flex and Core cost more per unit, so the same work costs more on them but comes in smaller steps.
- Weeks: the units over the block's units, buying one block of that type every week and taking one Focus after another.
| Block | Units | Price | Price per unit |
|---|---|---|---|
| Flex | 1 | $2,000 | $2,000 |
| Core | 2 | $3,750 | $1,875 |
| Dedicated | 4 | $7,000 | $1,750 |
Here is the fictional example from Project estimates. The units are for you; the client sees only the cost and weeks:
| Focus | Size | Low | Mid | High |
|---|---|---|---|---|
| Staff Access | S | 1 | 2 | 3 |
| Customer Scheduling | M | 3 | 4 | 6 |
| Technician Dispatch | L | 6 | 8 | 12 |
| Automated Notifications | S | 1 | 2 | 3 |
| Invoicing | L | 6 | 8 | 12 |
| Project capacity | 17 units | 24 units | 36 units | |
| On Flex | ~$34,000 17 weeks | ~$48,000 24 weeks | ~$72,000 36 weeks | |
| On Core | ~$31,875 8½ weeks | ~$45,000 12 weeks | ~$67,500 18 weeks | |
| On Dedicated | ~$29,750 4¼ weeks | ~$42,000 6 weeks | ~$63,000 9 weeks | |
- Say "approximately." A client often mixes blocks along the way, so the final amount usually falls between the blocks' figures.
- Weeks aren't a schedule. They assume one block of a type every week. More blocks a week shortens the timeline; fewer, or gaps between them, lengthen it.
- An estimate keeps its prices. It copies the block prices when it's made, so a later price change doesn't move it.
- Don't add hidden contingency. If the project carries risk that no Focus captures, write it down as a note or as a Focus and size it, so the client can see it.
- Don't turn the estimate into a block plan. Which block to buy next is decided at each Checkpoint.
- Include operations when Exalynt will run the software. The estimate then also shows the price of the operations plan, per month, quarter, and year from go-live.
Keeping estimates honest
- Don't fit the estimate to a budget. If the range is above what the client hoped, say so early and talk about which Focuses to drop, simplify, or defer. Change the scope, not the sizes.
- Don't add artificial precision. No fractional sizes, hour breakdowns, or single-number answers.
- Don't present Mid as a commitment. It's what the work takes if it goes as expected, shown alongside Low and High.
- Your payout doesn't depend on the estimate. You're paid for the blocks you fulfill (Engineer compensation), so there's no reason to push an estimate up or down.
Re-estimating
Revisit an estimate when meaningful information changes:
- A major assumption is invalidated.
- A Focus needs to do more, or a new Focus is added.
- A third-party integration behaves differently than expected.
- Discovery reveals substantially more or less complexity.
- The client materially changes the workflow they want.
Re-estimation is not an estimation failure. It's the expected response to better information. Update the affected Focuses, notes, and sizes, check the rollup again, and tell the client what changed and why, at the next checkpoint or sooner if the change is significant.
Frequently asked questions
What if a client asks for a single number?
Give all three. If they want one number to plan around, Mid is what the work takes if it goes as expected, but present it with Low and High and never as a commitment.
What if my estimate is far above what the client expected?
Tell them early and explain what drives the range: the Focuses, the uncertainty, and the assumptions in the notes. Then discuss scope. Dropping, simplifying, or deferring Focuses is a good conversation; shrinking sizes to fit a budget isn't. Smaller blocks spread the same work over more weeks, which can help a client's cash flow, but they don't make it cheaper.
Which block should I plan a Focus at?
None. Every Focus, and the project, is shown on every block, so the client can see what each would cost and take. Which block to buy is the client's choice, made one iteration at a time.
Can I estimate in hours first and convert?
No. Sizes are a judgment of capacity and uncertainty, and converting from hours adds precision the estimate doesn't have. Size in capacity units; the client sees cost and weeks.
Is a Focus the same as a Feature?
Not always. A Focus is whatever the work is grouped by. It's often a new Feature, but it can just as well be an improvement to an existing system, such as new Capabilities for a Feature the client already has.
How much should a Focus's notes say?
Enough to show its boundary, what's included and any important "cannot", and the assumptions that would change the size. There's no target count, and the count alone shouldn't set the size.
What if the work is heading past the High estimate?
Raise it as soon as you see it, not at the end. Usually the scope or an assumption has changed, so re-estimate and explain why. Inside a block, the price doesn't change and Exalynt absorbs the variance (Sharing risk).