Decision Support Before Implementation
The cheapest hour in any project is the one spent before it starts. We check the assumptions, compare the offers on equal terms and cut the scope down to what actually has to exist first.
The decisions made before the first commit
By the time a project starts, most of its cost is already determined. The scope has been agreed, the supplier chosen, the platform assumed, the deadline set against a date somebody said in a meeting. What follows is mostly execution of choices that were made quickly and rarely written down.
This work happens before that. It is short, it produces a document rather than software, and its whole value is in questions being asked while the answers are still cheap to act on.
Comparing offers that were never comparable
Three quotes for the same project routinely differ by a large multiple, and the reason is almost never that one supplier is that much more efficient.
They differ because they include different things. One assumes you provide the designs. One includes a year of maintenance. One quotes for the integration and one lists it as a dependency on your side. One transfers the code to you and one licenses it. Set side by side without normalising, the cheapest number wins and you find the difference later, usually at the point where you have least leverage.
We put them into the same structure and ask the questions the documents leave open: what happens when scope changes, who owns the repository, what the handover contains, and what it would take to move to another supplier in two years. Then the comparison is about the work rather than the formatting.
Testing the assumptions the plan rests on
Almost every plan depends on a small number of assumptions that nobody has checked. The pattern is consistent.
The integration exists. It usually does, but not always in the form the plan needs. The API might be read-only where the plan requires writes, or paginated in a way that makes the sync take hours.
The rate limits are sufficient. Documented limits are frequently well below what the intended workload implies, and discovering that after the build means redesigning the sync.
The data can be migrated. The old system exports, but the export is missing a field the new process depends on, or the historical records are inconsistent in a way nobody noticed while a human was reading them one at a time.
The deadline is fixed. Sometimes it genuinely is, tied to a contract or a season. Often it is a preference that has hardened, and knowing which one it is changes the entire shape of the plan.
Checking these means reading the actual documentation and, where that is not conclusive, spending a short amount of time proving it. That is a small cost against discovering it halfway through a build.
Cutting scope without gutting the project
Most first releases are too large, and the reason is understandable: every feature has someone who wants it and no obvious argument against it.
The way through is to decide what the first release has to prove, then test each item against that. Does the release fail to answer its question if this is missing? Usually the answer is no, for most of the list. What is cut is not wrong. It is early.
The part that matters is writing down what was removed and why. Undocumented cuts return as a crisis just before launch, argued from memory. Documented cuts return as a decision, revisited with evidence from the release you actually shipped.
When the recommendation is to stop
A meaningful share of these engagements end with advice not to proceed as planned. An existing tool already covers most of the need. The problem is a process that will survive being automated. A dependency is not ready and building around it costs more than waiting.
That is not a failed engagement. Deciding not to start is the least expensive decision available at this point, and it stops being available very quickly once contracts are signed and a team is assembled.
What you get
Offers compared on the same terms
Quotes from different suppliers are rarely comparable as written. We normalise them: what is in scope, what is billed separately, who owns the code, what maintenance costs after launch and what leaving would involve.
MVP scope with an explicit cut list
Not just what the first release contains, but what was removed and what each removal costs you in the meantime. A cut nobody wrote down comes back as a surprise three weeks before launch.
Technical assumption check
We verify the assumptions the plan depends on against the actual documentation: API capabilities, rate limits, data export formats, licence terms. Plans routinely assume an integration exists that does not.
Risk register with mitigations
The specific things that could derail this project, ranked, each with what would make it less likely or less damaging. Vague risk lists are decoration; useful ones name the system and the failure.
Cost and effort ranges
An independent estimate expressed as a range with the drivers named, so you can see which parts of the scope carry the uncertainty rather than arguing about a single number.
Written recommendation
A clear position on what to do, including the argument against it. If we recommend building, we say what would make buying the better call, and the other way round.
How we work
- 01
Establish what is actually being decided
Often the stated question is not the real one. 'Which supplier' is sometimes really 'should this be a system at all, or a change to a process'. We separate the decisions that are reversible from the ones that are not.
- 02
Collect the constraints
Budget shape, deadlines that are real versus preferred, existing contracts, who will maintain this afterwards, and what your team can realistically absorb alongside their current work.
- 03
Verify assumptions against sources
We read the API documentation, the licence terms and the data formats rather than trusting a summary. Where something is genuinely uncertain, a short spike is cheaper than discovering it mid-build.
- 04
Compare the options
Each realistic path costed and described in the same structure, including doing nothing for now. Making the status quo an explicit option keeps the comparison honest.
- 05
Recommend, then hand over
You get a written recommendation with its reasoning and a list of questions to put to your shortlisted suppliers. The point is that you can run the rest of the process without us.
Tools and technology
Where a solid open-source tool exists, we choose it over a closed one. No lock-in to a single vendor, and costs you can actually predict.
- n8n
- Supabase
- PostgreSQL
- Next.js
- Medusa
- Directus
- Keycloak
- Figma
- Linear
- Notion
- Stripe
- Shopify
Frequently asked questions
More services in this category
Technology Strategy
Technology strategy is a short list of decisions that are cheap to make once and expensive to revisit. We help you make them deliberately, with the tradeoffs written down.
Current Solutions Audit
An audit turns a vague sense that something is wrong into a ranked list you can act on: what is actually risky, what is merely untidy, and what will break first as you grow.
System Modernization and Scaling
Systems rarely fail outright. They get slow to change, expensive to run and fragile to deploy. The fix is a planned sequence of small replacements, not a rewrite.
Read testimonials from companies that trusted us
Delivered well ahead of the deadline.
ZanReal's individual approach is impressive.
Knowledge and business intuition make them a valuable partner.
Quick solutions that reduced costs by 99%.
About to sign off on a scope or a supplier?
Message usSend us the scope or the quotes you are weighing, and we will tell you which assumptions we would verify first and how a review before signing would run.
Can't keep up with changes in AI world?
Let us do the heavy lifting. Every week we distill the most important AI developments into a focused 5-minute briefing — so you stay ahead without the noise.
Find out more