How we estimate work across unknown technology

Estimate the unknown with a spike and a range. Do not sell a fixed number on a mystery repo.

Do not price a mystery

Estimate the unknown with a spike and a range. Do not sell a fixed number on a mystery repo. Unknown technology is not a moral problem. It is an information problem. The answer is to learn deliberately, then estimate with less pretending.

Avoits can work across stacks, but skill across stacks does not remove the need to inspect. A repo may be small and clean. It may hide years of patches, missing credentials, broken deploys, and business rules stored in comments. The estimate should respect that.

The first estimate is for learning

When the codebase is unknown, the first useful estimate is often a spike. A spike has a time box and questions. Can the app run locally. Where does the feature live. What framework version matters. How does deploy happen. What data or provider access blocks the work.

That learning is not overhead. It is how the real estimate becomes honest.

The spike should produce artifacts, not vibes. Notes on setup. A risk list. A diagram of the key path. A recommendation. A range. Maybe a small proof that the risky change is possible. The client should be able to see what was learned and why the next estimate changed.

What changes the range

Ranges are more honest than guesses

A range is not weakness. It is the right shape when uncertainty is real. The range should narrow as evidence improves. If it does not narrow, either the unknowns remain large or the work is changing.

We explain what would move the range up or down. Access today may reduce risk. Missing provider credentials may increase it. A running test suite may shorten work. A fragile deploy may make every change slower.

We also separate confidence from optimism. A narrow range with weak evidence is not better than a wider range with clear reasons. The goal is not to sound certain. The goal is to help the client make a decision with the uncertainty visible.

We separate repair from rebuild

A client may ask for a feature. The first discovery may reveal the system needs repair before feature work is safe. That does not automatically mean rebuild. It means repair and feature should not be priced as the same task.

Sometimes the right first release is stabilization: run the app, restore backups, update dependencies, document deploy, and fix the worst failure. Then feature work can proceed without every change feeling risky.

Repair work should still have outcomes. "Clean up the codebase" is too vague. "Make deploy repeatable, remove the abandoned payment plugin, and add logging to checkout errors" is a useful stabilization scope. Unknown technology gets safer when repair is named in business terms.

A spike checklist

1. Define the business question the estimate must answer.
2. Get code, environment, provider, and deployment access.
3. Run the app or identify exactly why it cannot run.
4. Find the feature area and its dependencies.
5. Check database shape and migration history.
6. Review deploy and rollback path.
7. Look for tests, logs, and monitoring.
8. Name blockers, risks, and assumptions.
9. Recommend repair, build, replace, or deeper discovery.
10. Turn the next step into a range with reasons.

Fixed scope can come later

Fixed scope works when the job and system are known. It does not work when both are foggy. A short learning phase can make later fixed scope safer for everyone. It gives the client a clearer decision and gives the studio a better chance of delivering.

This matches how we scope a software project. Scope is not a guess dressed as confidence. It is a shared model of work, risk, and outcome.

What we will not guess

We will not guess provider behavior without access. We will not guess data cleanup from a screenshot. We will not guess deploy risk from a homepage. We will not guess old plugin compatibility because the feature sounds small. Those guesses create bad projects.

We can give a rough order of magnitude. We can price a spike. We can explain likely risks from experience. But we will label guesses as guesses.

This protects both sides. The client does not get trapped by a confident number that later becomes a change request. The studio does not get rewarded for pretending. Better estimates come from better evidence, and better evidence comes from focused access.

Unknown does not mean unlimited

A spike should not become an endless audit. The questions need edges. If the goal is adding a payment method, the spike should focus on checkout, provider integration, order states, deploy, and tests. If the goal is rescuing performance, it should focus on the slow paths.

Discipline protects the client. It also keeps discovery practical.

We time-box the unknowns that block the next decision and park the rest. A legacy admin screen may be ugly but irrelevant to the requested checkout fix. An old package may need later attention but not block the first repair. Estimating well means knowing what to ignore for now.

At the end, we make the parked risks visible. They should not disappear just because they are out of scope today. A short "not now" list helps the client understand future trade-offs and prevents every old problem from being rediscovered in the next conversation.

What this means if you talk to us

Bring the repo, current system access, desired outcome, and any deadline. If you only have a live site and no code yet, tell us. That changes the first step. We may begin with a short call, then a spike, then a range.

The service may sit anywhere in our work, depending on what the unknown system is. The method stays the same: learn enough to stop pretending, then estimate the next useful move.

Expect us to ask for awkward details. Who last deployed it. Which provider is involved. Whether backups have been restored. Which feature scares the team. These questions are not bureaucracy. They are how an estimate becomes attached to the system instead of floating above it.

After the first learning step, we can usually separate quick wins from real projects. A quick win may fix an urgent pain. A project may need scope, design, and staged releases. Both are valid. Mixing them into one guess is where estimates go bad.

That separation helps budget too. A client can approve a small repair with confidence and plan a larger release with better information. Unknown technology becomes manageable when decisions are sized to the evidence available.