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, each in capacity units and approximate dollars. 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 Features that together produce a broader client outcome. | Replace phone-and-spreadsheet scheduling with an online portal. |
| Feature | A cohesive unit of functionality with value the client or user would recognize. One sentence. | Dispatchers can assign technicians to scheduled service appointments. |
| Capability | What a user, system, or Feature can or cannot do. Sets the Feature's current boundary. One line. | Users cannot access projects belonging to another organization. |
| Assumption | A condition the estimate currently depends on. One line. | Existing Clerk organizations will be used for client tenancy. |
| T-shirt size | Your coarse judgment of a Feature's capacity and uncertainty: S, M, L, or XL. | Dispatch board: 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 estimate a Feature 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 a client reference in hours to describe their scale, but estimates are expressed in units and dollars only.
The process
Keep it proportionate. The goal is a useful planning range, not a specification.
The Exalynt estimator is a quick way to build an estimate, including live with a client. Add Features, Capabilities, and Assumptions, pick a size for each, and it handles steps 6 to 8 for you: each Feature's range, the project rollup, and approximate dollars. You can print it or save it as a PDF to share.
- 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 major Features. Include foundational work the client benefits from, such as sign-in or getting to production, written as behavior like any other Feature.
- Write the important Capabilities for each Feature: enough to show its boundary, not every edge case.
- Write the important Assumptions, especially the ones that would move the estimate if they turned out false.
- Size each Feature S, M, L, or XL using your judgment (Sizing a Feature).
- Translate each size into its Low, Mid, and High range of capacity units.
- Roll the Features up into project Low, Mid, and High by adding them (Rolling up).
- Translate the three totals into approximate dollars at the client's per-unit price.
- Review the result. Is any obvious scope missing? Is there uncertainty no Feature or Assumption 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 Low, Mid, and High in units and dollars, then the Features, Capabilities, and Assumptions behind them.
Writing Features, Capabilities, and Assumptions
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. |
- One line each. If a Feature needs a paragraph, it's probably several Features.
- 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 an Assumption 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.
Sizing a Feature
Each size maps to a Low, Mid, and High range of capacity units:
| Size | Low | Mid | High | Often looks like |
|---|---|---|---|---|
| S | 1 unit | 2 units | 3 units | Narrow, familiar behavior with few unknowns. |
| M | 3 units | 4 units | 6 units | A clear feature with some workflow, roles, or states to work through. |
| L | 6 units | 8 units | 12 units | Broad behavior, several roles or states, or an integration with a system Exalynt doesn't control. |
| XL | 12 units | 16 units | 24 units | Large or substantially uncertain. Usually a sign to split it into smaller Features. |
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 Capabilities. A few difficult Capabilities can need far more capacity than many straightforward ones.
- Weigh both known and unknown complexity. Uncertainty is part of the estimate. A Feature 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 Features will rarely take identical capacity. That's why each size is a range.
- Treat XL as a prompt to split. If a Feature can't be split because too much is unknown, say what would reduce the uncertainty, such as spending an early iteration on discovery.
What can increase a size or widen the range
| Area | Factors |
|---|---|
| Scope | Broader or less clearly bounded behavior. More Capabilities. 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 Features' Lows, Mids, and Highs. The dollars are those totals at the client's per-unit price: $2,000 on Exalynt Managed or $2,250 on Self Managed. Here is the fictional example from Project estimates:
| Feature | Size | Low | Mid | High |
|---|---|---|---|---|
| Staff sign-in | S | 1 | 2 | 3 |
| Online booking | M | 3 | 4 | 6 |
| Dispatch board | L | 6 | 8 | 12 |
| Appointment reminders | S | 1 | 2 | 3 |
| Invoicing | L | 6 | 8 | 12 |
| Project capacity | 17 units | 24 units | 36 units | |
| Approximate investment (Exalynt Managed) | ~$34,000 | ~$48,000 | ~$72,000 | |
- Say "approximately." Flex and Core carry a fragmentation premium, so the final amount depends on which blocks the client chooses along the way.
- Don't add hidden contingency. If the project carries risk that no Feature captures, write it down as an Assumption or a Feature and size it, so the client can see it.
- Don't turn the estimate into a block plan or schedule. Which block to buy next is decided at each Checkpoint.
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 Features to drop, simplify, or defer. Change the scope, not the sizes.
- Don't add artificial precision. No fractional units, hour breakdowns, or single-number answers.
- Don't present Mid as a commitment. It's the current planning expectation, 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.
- New Capabilities are 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 Capabilities, Assumptions, and sizes, roll the estimate up 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 the current planning expectation, 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 Features, the uncertainty, and the Assumptions. Then discuss scope. Dropping, simplifying, or deferring Features is a good conversation; shrinking sizes to fit a budget isn't.
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. Estimates are expressed in capacity units and dollars only.
How many Capabilities should a Feature have?
Enough to show its boundary: what's included, and any important "cannot". 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).