Spec first. Always.
Here's exactly how.
Every project starts with a 1-page Definition of Done — agreed before any code is written. Fixed price, working demo before final payment, full handover.
Describe the problem
- Tell us what's slowing the floor down — not what feature you want, just what problem you're solving.
- We ask clarifying questions: who uses this, when do they use it, what does success look like on day 1 and day 90?
- No spec needed from you. That's our job.
We write the spec
- We write a 1-page Definition of Done: exactly what gets built, what doesn't, and how we'll know it works.
- The spec includes the user workflow, key screens or outputs, data sources, and acceptance criteria.
- This is the contract. Scope is locked the moment you sign off.
You approve and lock it
- Review the spec. Ask questions. Request changes. This is the moment to get it right.
- Once you approve, the price and scope are locked. No surprises on the invoice.
- 50% payment at this point to reserve our capacity and start the build.
We build to spec
- Every change is a pull request with a full description. You can see progress in real time in GitHub.
- Automated QA and Security review runs on every PR — the same pipeline, every time.
- Anything outside the spec becomes a change order, scoped and priced before we start it.
Working demo
- You see the tool running before you pay the second half. Walk through it yourself.
- We check it against the spec together. If something doesn't match, we fix it before you pay.
- The working demo is the acceptance gate — not a sign-off on a document.
You own it
- Full source code delivered to your GitHub repository. Your team can read, modify, and maintain it.
- Documentation included: how to run it, how to configure it, what the key components do.
- Final 50% payment. No lock-in, no ongoing dependency on Crescera unless you want the retainer.
Why spec first?
Every scope dispute, surprise invoice, and delayed project we've seen had the same root cause: no one agreed on what “done” meant before the work started.
Prevents scope creep
When scope is defined in writing before the build starts, there's no ambiguity about what was or wasn't in the project.
Protects your budget
A locked spec means a locked price. You know exactly what you're paying before a line of code is written.
Aligns expectations
Both sides agree on what 'done' looks like. No disagreements at delivery about whether the work is complete.
Enables honest change orders
When you want something that wasn't in the spec, we scope it separately. You decide whether it's worth it.
Common questions
What if I don't know what I need?
Start with the Operations Tech Assessment. One session maps the pain, identifies the highest-value tool to build, and gives you a rough cost and timeline. Then you decide whether to proceed.
What systems can you integrate with?
Anything with an API or data export — PLCs via SCADA, ERP systems, Slack, email, and more. If you're not sure, tell us what you have and we'll tell you what's feasible.
What if I want changes during the build?
Changes outside the approved spec become change orders: scoped in writing, priced, and approved by you before we start. Nothing gets added without your sign-off.
How long does the spec step take?
Usually 1–2 business days after our initial call. We write the first draft and iterate with you until it's right. Simple tools are faster; multi-workflow systems take longer.
What does 'working demo' mean?
A live, deployed version of the tool running your actual (or realistic test) data. You can click through it, not just watch a screen recording. If it doesn't match the spec, we keep building.
Can my team maintain the code after delivery?
Yes. You receive the full source code, documentation, and enough context for a competent developer to understand and extend it. We build with that handoff in mind.