HOW WE WORK
The whole process, in writing.
We have no case studies yet, so this page carries the weight they would. Everything here is a commitment you can hold us to: what you receive, when, and what happens when something goes wrong.
THE FRAMEWORK
Innovate. Build. Deliver.
Three phases, not three departments. The same people carry the work from the first conversation to the handover, and every phase ends with something written down.
- 01
INNOVATE
Weeks 1–3We refuse to quote until we understand the problem.
Discovery and architecture. We talk to the people who will use the system, the people who will operate it, and the person who gets blamed if it breaks. Then we write down what we found, what we propose, and what we are not solving.
- Problem framing document
- Solution architecture
- Technology decision record, naming the options we rejected and why
- Fixed scope and estimate
- Risk register
- 02
BUILD
Two-week cadenceWorking software, not status reports.
A staging URL by day fourteen, then a shippable increment every fortnight. You see the work running rather than described, early enough that changing direction is still cheap.
- Staging URL by day 14
- A shippable increment every fortnight
- Automated tests and CI on every merge
- A live demo each sprint
- A burn-down you can see
- 03
DELIVER
Launch and beyondThe handover is the product.
Production deployment and the operational knowledge to run it without us. If the only way to keep the system alive is to keep paying us, we have failed at this phase.
- Production deployment and infrastructure as code
- Runbooks and monitoring
- Full knowledge transfer to your team
- Optional managed support SLA
- A codebase your next engineer can read
WHAT YOU RECEIVE
Artifacts, not status updates.
Every phase ends with something you can read, argue with, and hand to someone else. These documents are yours to keep — including if you decide not to work with us.
Problem framing document
Innovate
The problem in plain language, the constraints that are real, the constraints that turned out to be habits, and what success looks like in terms someone could measure. Four to six pages.
Solution architecture
Innovate
Components, data model, where state lives, how it deploys, and what happens when a piece of it fails. The diagram is not the document; the reasoning is.
Technology decision record
Innovate
For each significant choice: what we picked, what we rejected, and the trade-off we accepted. The rejected options matter more than the chosen one.
Fixed scope and estimate
Innovate
What we understand well enough to commit to. Where genuine uncertainty remains we price that part separately rather than burying a contingency in the total.
Risk register
Innovate
What could go wrong, how likely, what it would cost, and what we would do about it. Some entries will be about your organisation rather than ours.
Staging environment
Build
A URL by day fourteen, then a shippable increment every fortnight. Something running that you can open on your phone and show someone.
Sprint demo and burn-down
Build
A live demo each sprint and a burn-down you can see, so progress is observable rather than reported.
Runbooks and monitoring
Deliver
How to operate it, what to watch, and what to do at three in the morning when something is wrong.
Knowledge transfer
Deliver
Working sessions with your engineers, not a document dump. The test is whether your team can ship the next feature without us.
Want to see the quality before you commit? Ask for a redacted architecture decision record from a past project and we will send one. info@genrocktechnologies.com
ENGAGEMENT MODELS
Three ways to work with us.
The choice is not about price. It is about who carries the uncertainty, and how much of it there actually is.
Fixed-scope Sprint
You buy an outcome. The risk of it taking longer than estimated sits with us.
Best when
- You can describe the finished thing in a paragraph
- The requirement is unlikely to move while it is built
- Someone needs to approve a defined number
- You want a hard stop, to test the partnership before committing further
Watch for
Change requests become commercial conversations, because they have to. If your requirement is still moving, this model turns healthy learning into negotiation.
Dedicated Team
You buy capacity. We work to your backlog on a two-week cadence; the risk of building the wrong thing sits with you.
Best when
- You are still learning what to build
- Priorities shift faster than a contract can
- The work is a product with a roadmap, not a project with a finish line
- You want engineers who will tell you the plan is wrong
Watch for
Capacity without direction produces motion without progress. This model needs someone on your side who owns the backlog and can say no.
Advisory Retainer
Architecture review, technology decisions and code review for a team you already have.
Best when
- The people are in place and the risk is in the direction
- You are about to commit to an architecture nobody has pressure-tested
- You need a second opinion with no incentive to win the build
Watch for
This only works if we can be candid. If the goal is a document endorsing a decision already made, we are the wrong firm.
Genuinely unsure which fits? Take a fixed-scope discovery first. Two weeks, fixed price, and at the end you choose the model on evidence rather than instinct — with the documents in your hands either way.
ENGINEERING STANDARDS
Gates, not guidelines.
A standard nobody enforces is a preference, and preferences erode under deadline. Everything below runs automatically and fails the build when it is breached. This website is the worked example — every gate listed here runs on the repository that produced the page you are reading.
Before a commit lands
- ESLint with --fix and Prettier run on staged files
- TypeScript compiles with no errors (tsc --noEmit)
On every pull request
- Typecheck, lint and production build
- Playwright suite against the production build, on desktop and mobile
- Lighthouse CI, median of three runs, against a failing budget
- Worker bundle size reported against the 3 MiB platform cap
Before anything deploys
- Both the quality and bundle-size jobs must pass first
- Deploy runs only on the main branch, never from a pull request
The budget that fails the build
- Accessibility
- 100
- Best practices
- 100
- SEO
- 100
- Performance
- 95 minimum
- Largest contentful paint
- 2500 ms
- Cumulative layout shift
- 0.03
- Total blocking time
- 200 ms
- JavaScript
- 215 KB
- CSS
- 25 KB
- Fonts
- 92 KB
- Total page weight
- 500 KB
- Third-party scripts
- zero
Types and structure
- TypeScript strict mode, plus noUncheckedIndexedAccess, noImplicitOverride, noUnusedLocals and noUnusedParameters
- No any and no @ts-ignore reaches the main branch
- Server Components by default; a client boundary has to justify itself in a comment
- Every colour, size and spacing value resolves to a design token -- no hardcoded hex anywhere in a component
Security baseline
- Content-Security-Policy, with no third-party script origins permitted
- Strict-Transport-Security with preload
- X-Frame-Options: DENY and X-Content-Type-Options: nosniff
- Referrer-Policy and Permissions-Policy set explicitly
The test suite
Runs against the production build on every pull request, on a desktop and a mobile viewport. Each spec below is a file in the repository.
Accessibility
a11y.spec.ts
axe-core against WCAG 2.2 AA on every public page. Zero violations, or the build fails.
Contrast
contrast.spec.ts
Every visible text element measured against the background it actually sits on, from rendered styles rather than a colour palette. A secondary-text token once shipped at 4.27:1 because the audit had checked it against white; this is the test that would have caught it.
Structure
structure.spec.ts
One h1 per page, no skipped heading levels, the skip link is the first thing Tab reaches, and every JSON-LD block parses and matches the visible content it describes.
Keyboard
keyboard.spec.ts
The mobile navigation opens, traps focus, moves between items with the arrow keys, closes on Escape and returns focus to where it started. Every target is at least 44px.
What we will not quote is a coverage percentage or an OWASP ASVS level. The right floor differs between a marketing site and a payments system, and so does the right security baseline. Both are set in writing at the start of an engagement, in the same decision record as the architecture, and then enforced in CI the way the suite above is enforced here.
COMMUNICATION
How we stay in contact.
Most engagements go wrong in the gaps between conversations, not in the code. So the channels, the hours and the escalation path are agreed at kickoff rather than left to improvise.
A shared channel, not a ticket queue
We work in a Slack Connect channel shared with your team, so questions are asked in the open and answers stay searchable. If your organisation uses Teams instead, we use that.
A fixed overlap window
We are in Indore (IST). We hold an agreed overlap with your working day for standups and reviews, set at kickoff and written into the engagement document rather than negotiated weekly.
One business day, in writing
Written messages get a reply within one business day. Not always the answer — sometimes it is an acknowledgement and a date — but never silence.
A named escalation path
You get the name of the engineer running the work and the name of the person above them, both before the engagement starts. Escalating should never mean guessing who to email.
Demos you can attend
A live demo each sprint, recorded for anyone who could not make it. Progress is shown, not reported.
CONTRACTS
Paperwork that protects both sides.
We keep the legal structure boring for the same reason we keep the architecture boring: so nobody is surprised later.
Master services agreement plus statements of work
One MSA covers the relationship. Each piece of work gets its own SOW with the scope, deliverables, timeline and commercial terms. New work means a new SOW, not a renegotiated MSA.
NDA on request
We will sign a mutual NDA before the first discovery conversation if you want one. We do not need to know your idea to tell you whether we can help; we do need to know it to quote.
IP assigns to you on payment
Everything we build for you is yours from commit one — private repository in your organisation, your cloud account, your domain. Formal assignment of intellectual property completes on payment of the invoice for that work.
Data processing agreement for EU clients
If you are subject to GDPR, we sign a DPA covering our role as processor. We will also tell you plainly which of our tools touch personal data, so the agreement describes what actually happens.
A WORKED EXAMPLE
Eight weeks, week by week.
This is illustrative. It is not a past project and the client does not exist. It shows how the framework plays out on a typical fixed-scope build: a customer-facing web application with a small internal admin, replacing a spreadsheet-and-email process.
- Week 1Innovate
Discovery
Interviews with the people who use the current process, the people who operate it, and the person accountable for it. We read the spreadsheet, the support inbox, and whatever passes for documentation. Output: a draft problem framing document by Friday.
- Week 2Innovate
Architecture and scope
The solution architecture and the technology decision record. Two options are seriously considered for the data layer and one is rejected in writing. The scope is fixed, the estimate is agreed, and the risk register has four entries — one of which is about a dependency on your side.
- Week 3Build
Foundations
Repository in your organisation. CI with typecheck, lint and tests on every merge. Infrastructure as code for a staging environment. Nothing user-facing yet, and that is deliberate: the pipeline is proven before anything interesting is built on it.
- Week 4Build
First staging release
Day fourteen of the build. A staging URL with the first end-to-end flow working: one real user journey, thin but complete. First sprint demo. You can open it on your phone and show someone.
- Week 5Build
Second increment
The admin side takes shape. A change request arrives — it always does — and is handled as a change: costed, agreed, and added to the SOW, not absorbed silently and paid for in week eight.
- Week 6Build
Third increment
Remaining flows, edge cases, and the first pass at monitoring and alerting. Second sprint demo. The burn-down says what it says; if it is behind, that conversation happens now rather than in week eight.
- Week 7Deliver
Hardening and handover begins
Runbooks written. Knowledge-transfer sessions start with your engineers: they ship a small change to staging themselves, with us watching rather than driving. Security headers, backups and access controls reviewed against what the decision record promised.
- Week 8Deliver
Production
Deployment to production through the same pipeline that has been running since week three. Final knowledge transfer. Handover pack: architecture, decision record, runbooks, and a list of what we would do next — which you are free to do with anyone.
QUESTIONS
About working together.
Can we skip discovery and go straight to building?
On a dedicated-team engagement, yes, if you already have a backlog and an architecture. On a fixed-scope sprint, no. A fixed price on work nobody has understood yet is not an estimate; it is a hope with a decimal point. Discovery is what makes the number honest.
What if we stop after discovery?
You keep everything: the problem framing, the architecture, the decision record, the estimate and the risk register. They are written to be useful independently of who builds the system. Any competent firm can quote against them more accurately than they could have before.
Who actually does the work?
The engineers on your discovery call. We name them before you sign, and they stay on the engagement. If someone has to change, you hear about it from us first, with a handover, not by noticing a new name in the repository.
How do you handle changes mid-project?
As changes. A request is costed, agreed and added to the statement of work before it is built. On a dedicated team it simply enters the backlog and you decide its priority. What we will not do is absorb scope silently and recover the cost somewhere less visible.
What happens if the project is behind?
You know at the sprint demo, not at the deadline. The burn-down is visible throughout. If we are behind, the conversation is about what to cut, what to defer, or what it costs to recover, and it happens as soon as the trend is clear rather than when it is too late to act on.
What does the handover actually include?
Production deployment through the same pipeline used since week one, infrastructure as code, runbooks, monitoring, and working sessions where your engineers ship a change themselves while we watch. The test of a handover is whether your team can build the next feature without us.