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.
Vishal stays close to a limited number of consequential engagements at a time. If the fit is not right, he will say so early.
Building software right means settling four things in writing before money moves: the scope boundary and its explicit non-goals, the architecture shape and the load assumption behind it, who owns the code and how each milestone is accepted, and the named trigger that forces the estimate to be redone.
Two properties matter more than any single line. It is 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, because a record you cannot take to another vendor is a quote with a diagnosis stapled to the front.
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.
A quote that cannot answer all three in writing is not comparable to any other quote you hold.
Each one ends in something that physically leaves the room. A phase with no artefact at the end of it is a status meeting.
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
A named deliverable built to an agreed definition of done, priced before it starts rather than billed as it runs.
Bring the scope you want quoted: Scope a delivery
Monthly, per engineer · Rolling, starts with a trial week
A named engineer working your backlog inside your team, judged on real output before you commit to anything.
Or an engineer inside your team instead: Discuss an embedded engineer
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.
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.
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.
The asymmetry is the whole argument for doing this first. Across 1,471 IT projects, Bent Flyvbjerg and Alexander 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.Flyvbjerg and Budzier, submitted 28 March 2013 . Thirteen years old: read it as a finding about the distribution, not a current measurement.
Ownership is a contract term, not a default. Under US copyright law the starting position is that the creator owns what they create, so absent an explicit written assignment a buyer who has paid in full may hold a licence rather than the copyright. Jurisdictions differ and I am not your lawyer. What the decision record does is put 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 rather than a personal one.
Compare what the two quotes contain before you compare what they cost, because a price is a function of a scope and the scopes are almost never the same. 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.
Yes, and it is the most useful thing on this page for anyone holding quotes they cannot compare. The output is the same either way: 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.
Two things, deliberately kept apart. The judgement is mine and it is personal: the decision record carries my reasoning, and I stay close to a limited number of engagements so that stays true. Delivery is ViitorCloud’s, the engineering company I co-founded and serve as CTO. The sequence matters more than either fact. The record is produced first and it is portable, so you can take it to two other vendors and price mine against theirs.
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.
Best for leaders with a consequential problem, access to the people who live it, and the authority to act on what is learned. 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.