What a fixed-scope service should write down before you pay
A price only means something when the work behind it is described. Five things we believe every engineering service page should state in writing before any money moves.
Most disputes in software work are not about quality. They are about expectation: one side believed something was included, the other side never agreed to it. The cheapest way to prevent that argument is to write the scope down before anyone pays, in words both sides can point at later.
Every service in the Cryonity Labs catalogue is published with the same structure. Here is why each part is there, and what to look for when you read any engineering proposal, ours or anyone else's.
1. The deliverables, as nouns
A deliverable should be something you can hold up at the end and check off: a repository, a pipeline, a report, a recorded walkthrough, a set of screens. Verbs such as "support", "optimise" or "advise" describe activity, not output. If a line cannot be verified at handover, it is not really a deliverable.
Count them, too. A list of seven specific items is easier to accept or reject than a paragraph that implies twenty.
2. The timeline in working days
"Two to three weeks" invites a conversation about which week. A number of working days, counted from the point the brief and access are complete, gives both sides the same clock. It also makes the dependency visible: if access arrives late, the date moves by the same amount, and nobody has to argue about it.
3. Who the service is for, and who it is not for
An honest service page says which situations it suits. That section does as much work as the deliverables list, because it lets you rule a service out before you buy it. If none of the "ideal for" descriptions sound like you, that is useful information.
4. What we need from you
Every engineering engagement depends on something the client controls: credentials, a named decision-maker, sample data, sign-off on designs. Listing those inputs up front turns a common source of delay into a checklist you can prepare before kickoff.
5. The price, with tax inside it
We publish prices in rupees with 18% GST already included, so the number on the page is the number on the invoice. A price that changes once tax, platform fees or "setup" are added at checkout is not really a published price.
If a requirement is not on the page, ask before you pay. A written yes or no at that point is worth more than any assumption made later.
How to use this when comparing proposals
- Put two proposals side by side and list the deliverables of each as nouns. The gaps are usually obvious.
- Convert every timeline to working days from a clearly defined start point.
- Check whether the price includes GST and anything else charged at payment.
- Ask what happens if an input you are responsible for arrives late.
If you would like a second opinion on a quote you have received, our Engineering Counsel practice exists for exactly that kind of question.
Working on something like this?
Send a short brief and we will reply in writing with the service that fits.
