Development where the spec leads every step.
You describe what you need in your own words. We turn it into a spec you read and approve, and a time and budget estimate we meet. AI agents write and test the code, and experienced developers supervise and are accountable for every line. It is the method behind everything we do: systems for organizations, products for founders, automation, and the dev teams we coach.
The spec is the source. The code follows from it.
In most projects the spec is written once, and a month later it no longer describes the system. From then on only the code knows what the system does, and only the developer who wrote it can explain it. With us it works the other way round:
- Every change goes into the spec first, and only then into the code.
- The AI agents build from the spec, so it has to be precise and current.
- The names in the code match the spec, so any new developer understands what they are looking at.
- The spec and the code stay current and documented through delivery, and after it.
From the first call to a working system.
Intro call
One hour, free. At the end you will know what we understood, which questions are open, and what the spec phase will cost, at a fixed price.
From conversations to a spec
Spec meetings are recorded, and AI turns them into drafts. You speak in your own words, without writing requirements documents.
A spec in two versions
One version for you, to read and approve. A second for developers and agents, with everything from the rule book you did not know to ask for, written as “remember that” notes.
Approval and a binding estimate
You approve the spec and get a time and budget estimate we commit to. The spec is yours, even if you decide not to continue with us.
Build and test
AI agents write and test the code, and experienced developers supervise and are accountable for every line. In DocsRobot, our own product, an AI system tests the product every night, in Hebrew and English, and files its own bug reports.
Delivery, and after
Current, documented code and spec, available to you at any moment. Keep maintaining with us, or with any other team.
What exactly we commit to.
Our commitment to time and budget applies to the spec you approved. That is what lets us keep it, and what lets you check it.
- Want to change something midway? The change goes through the spec, and you see its effect on time and budget before you approve it, not after.
- Why is the spec paid? Because that is the part where we work for you rather than sell to you. At the end you have a document any team can work from.
- In our own product too: every new DocsRobot module was developed within the budget set for it in advance.
What no client asked for, and every spec of ours contains.
The development rule book is hundreds of rules gathered over decades, organized in chapters: UI/UX, security, performance and more. Every requirement is checked against it. A rule that applies and is not obvious goes into the developer version as a “remember that” note. Five examples, each with what you get and the rule itself:
How do you test something that happens once a month without waiting a month?
What you get: monthly billing, a weekly report, a yearly reminder. All fully tested before launch, not after the first month has passed.
The rule: any system with daily, weekly, monthly or yearly processes runs on a simulation clock we control, not on the server clock. In testing we move the clock forward and watch what happens.
A double click never charges twice.
What you get: no customers charged twice and no duplicate records.
The rule: every operation with side effects (creating a record, charging, sending an email, requesting a signature) takes an Idempotency-Key. The server claims the key atomically, stores the request hash with the final response, and returns that same response on every repeat. Same key with a different body: 409.
Two people edit the same record. Neither silently overwrites the other.
What you get: data integrity when people work together. Nobody’s work disappears without them knowing.
The rule: every editable record has a version exposed as an ETag header. An update must include If-Match with the version that was read. If the record changed in the meantime: 412, and the user gets a clear message. Never a silent last-write-wins, not even against background processes.
One customer’s data cannot reach another customer. By design.
What you get: isolation at the architecture level, with an automated test that runs on every build.
The rule: in a multi-tenant system the tenant identity comes only from the authenticated token, never from an ID sent in the body, a header or the URL. Filtering is enforced in one central place, so a missing filter is structurally impossible. Automated tests with two tenants confirm that A cannot see B through any endpoint.
When something goes wrong there is a reference number, and an external provider cannot take the system down.
What you get: a reference number that leads to the full picture within minutes. And when a payment provider, an email service or an AI model does not respond, the system keeps working on everything that does not depend on it.
The rule: every request gets a correlationId that is attached to every log line and every outgoing call, and shown to the user on a critical error. Every call to an external service is wrapped in a retry with exponential backoff and jitter, only for errors where a retry can succeed, and in a circuit breaker that opens after repeated failures.
Part of the spec, not a final step.
ISO 27001
We are certified to the international standard for information security management.
OWASP Top 10
Development is checked against the well-known list of web application risks, as part of the development rule book.
Automated penetration tests
On large projects we run automated penetration tests rather than waiting for an external audit to find a problem.
Server hardening
Servers we set up and manage are hardened before they go live, not after the first incident.
Where the method meets you.
Software for organizations
A new system, a legacy replacement even without source code, or AI inside an existing system.
Learn moreFor founders: prototype to production
From an idea, or a stuck prototype, to a product you can launch and raise money on.
Learn moreDev team modernization
The method, the tools and the rule book, installed with your dev team, with hands-on coaching.
Learn moreBusiness automation
Connecting the systems you already have, with the same care we put into software.
Learn moreBefore we start
What is Spec-Driven Development?
Who writes the code, AI or developers?
What if we want to change something midway?
What if we decide not to continue after the spec?
What is a “remember that” note in the spec?
Which technologies do you work with?
One hour. No commitment.
At the end you will know what we understood, which questions are open, and what the spec will cost. If we think it is not worth building, we will say that too.
Or directly: info [at] assembly-infotech.solutions
Plot no. E-309, Phase 8/A, Mohali, Punjab 160055, India