Custom Software Development
Build it right. Decide it before you sign.
Budget and a blank page, or three proposals that will not line up. Either way the same six things have to be true in writing before anybody starts. This page publishes them.
You leave with the scope boundary, the architecture shape and the three questions your quote has to answer — whether or not you build with me.
The decision record
Six things settled in writing before money moves. A record, not a proposal: it names the option that was rejected next to the one that was chosen, and it is written to be read by an engineer who has never spoken to me.
- The scope boundary, and what is explicitly not in itVersion one written as the things a user can do. Anything absent from that list is outside the price, agreed in writing before work starts.
- The load model, with a source for every numberUsers, records, requests, payload sizes, integrations. An architecture priced against an unstated load is priced against a guess.
- The architecture shape, and the condition that reverses itThe default, its module boundaries, and the named constraint under which a piece gets pulled out. A shape with no reversal condition is a preference in a decision’s clothes.
- Build versus buy, itemisedAuth, payments, search, analytics, error tracking, storage, email. One line each with a decision and a reason. Rewriting commodity infrastructure is the fastest way to spend a budget on nothing a customer sees.
- Acceptance criteria, per milestoneHow you know a milestone is finished, written before it starts, checkable by a non-technical sponsor. “Done” with no test behind it is an opinion, and it is normally the vendor’s.
- Ownership, and the trigger that forces a reforecastIP assigned on creation, repository and cloud accounts in your company’s name, and the named event that forces the estimate to be redone in the open.
Three questions any quote has to answer
You cannot judge a quote by its number, because the number is a function of a scope nobody has fixed. Send these to every vendor at once, so the answers are comparable.
Q1
What is explicitly not in version one?
Three proposals that differ by a factor of four almost always differ on scope by a factor of four. Silence here is where the change requests come from.
Q2
What load, in numbers, is this architecture priced against?
A stack list is a shopping receipt, not an architecture. Without a load figure the estimate is priced against whatever the vendor assumed and did not say.
Q3
Who owns the code, and on what date does ownership transfer?
Absent an explicit written assignment, a buyer who has paid in full may hold a licence rather than the copyright. This is the term buyers are most often surprised by.
A quote that cannot answer all three in writing is not comparable to any other quote you hold.
Four phases, four artefacts
Each one ends in something that physically leaves the room. A phase with no artefact at the end of it is a status meeting.
- DiscoveryThe problem, the users, the constraints, the integrations you do not control, and the dates the business cannot move. Load numbers get collected here, with sources.
- The decision recordThe six headings above, filled in against your project. Where a decision cannot be made yet, the record says what evidence would settle it.
- BuildMilestones with acceptance criteria written before each one starts, the reforecast trigger live from day one, and decisions logged with the rejected option.
- HandoverRunbook, environments, deploy procedure, credentials in your accounts, and the decision log. Designed in phase two rather than improvised at the end.
What building with me looks like
The difference is who carries the scope. Both come after the decision record, never before it, because a price quoted before a scope is a number attached to a guess.
Fixed scope, quoted · Defined outcome, defined end
Scoped Delivery
A named deliverable built to an agreed definition of done, priced before it starts rather than billed as it runs.
- Scope, acceptance criteria and end date agreed in writing first
- A team assembled for the shape of the work
- Vishal accountable for architecture and the release decision
- Everything produced is yours, whatever happens next
Monthly, per engineer · Rolling, starts with a trial week
Embedded Engineer
A named engineer working your backlog inside your team, judged on real output before you commit to anything.
- One engineer embedded in your standup
- A trial week on your repo and your backlog before commitment
- Vishal accountable for technical direction, not delivery hours
- Scale up, scale down, or stop between months
I am not for hire. The team is. I am accountable for technical direction, for the architecture, and for the decision that a release is fit to ship. My hours are not the unit, and no version of this is priced as a share of my week. If you want engineers you direct yourself day to day, Hire is the page for that.
Why you should distrust this page, and what contains it
Delivery runs through ViitorCloud, so a build is the largest engagement I could sell you. That is exactly why the decision record is written to be handed to a vendor who is not me: scope boundary, architecture shape and the terms your contract has to carry, in a form two other firms can quote against.
That costs me leverage on purpose. A portable record is worth less to a seller of builds than a proposal is, which is what makes publishing one worth something to you. It also survives the test that matters: if the honest recommendation is build less than you planned, or validate before you build anything, the record can say so, because it is not the invoice.
The asymmetry is the whole argument for doing this first. Across 1,471 IT projects, Flyvbjerg and Budzier found a mean cost overrun of 27% — but one project in six was a black swan averaging a 200% cost overrun and roughly a 70% schedule overrun. Budget against the mean and you have budgeted for the case that would not have ended you anyway.
No project commitment. No predetermined technology. No pressure to proceed when the evidence says stop. And no figure quoted for work that has not been scoped.
Questions people ask first
Do I own the code you write?
Ownership is a contract term, not a default. Absent an explicit written assignment a buyer who has paid in full may hold a licence rather than the copyright. The decision record puts the assignment on the list of things that must exist in writing before money moves: effective on creation, covering subcontractors, with the repository and cloud accounts held in your company name. Confirm the wording with your own lawyer.
What if my quote from another agency is cheaper?
Compare what the two quotes contain before you compare what they cost. Run both against the three questions on this page. A cheaper quote that answers all three is a better quote and you should take it. A cheaper quote that answers one is not cheaper; it is a smaller number attached to a larger unknown, and the difference arrives later as change requests.
Can you review a proposal I already have, without building it?
Yes, and it is the most useful thing on this page for anyone holding quotes they cannot compare. The output: what the proposal settles, what it leaves open, what it silently assumes about load, and the questions to send back before you sign. It is written for you to use with that vendor, not to move the work to me.
Who is accountable, you or ViitorCloud?
Two things, deliberately kept apart. The judgement is mine and it is personal: the decision record carries my reasoning. Delivery is ViitorCloud’s, the engineering company I co-founded and serve as CTO. The record is produced first and it is portable, so you can take it to two other vendors and price mine against theirs.
Bring the quote, or bring the blank page
Either one gets the same first move: fix the scope boundary, state the load the architecture has to carry, and name the terms that must exist in writing before money moves.
In the age of AI
The advantage was never the model. It's knowing what to build with it — and having a team that can actually ship it.
That's the part I help with: finding where AI genuinely makes your business faster, deciding what's worth building, and standing behind it once it's live.
Four offices, one very full passport
Every dot on this map is a conversation I still remember.
- Where I've spoken
- Office
