No surprises is a process, not a promise
Here's how an engagement is shaped, what the first two weeks look like, what we commit to every week after that, and what you own throughout. Written down so you can hold us to it.
Pick the one that matches your situation
Most work falls into one of these. They can also run in sequence: a build that turns into an embedded team, a rebuild that becomes a maintenance arrangement, or a sprint that answers whether there's a build worth starting at all.
New build
You have a product in mind and no engineering team to build it yet. We take the whole technical side: product shape, architecture, build, launch, and the infrastructure underneath. Not a helping hand on someone else's plan, and not a prototype you outgrow in six months. What ships is built to carry a million users, and to hand over to your own team once you have one.
- A first version that needs to be real, not a clickable mock
- A funding or customer deadline you're building toward
- No in-house engineering leadership yet
Rescue & rebuild
Something already exists and it's getting in the way: slow, fragile, or written by people who've since left. We stabilise it first, then replace it in pieces while it keeps serving traffic.
- Releases have become risky enough that you avoid them
- One part of the system causes most of the incidents
- A rewrite has been discussed and keeps getting postponed
Embedded team
You have a team and a roadmap longer than your capacity. We take whole slices of it (a service, a surface, a platform area) and own delivery inside your process, not alongside it.
- Your roadmap is clear and the constraint is bandwidth
- You want engineers in your standups, not a separate vendor track
- Work can be split into areas somebody can own end to end
Run & maintain
Software that shipped still needs someone watching it. We handle monitoring, dependency and security updates, incident response, and the small fixes that otherwise pile up for a year.
- The product is live and nobody is clearly on call
- Dependencies and certificates have drifted out of date
- You need a fix path for bugs without pulling a product team off roadmap
AI sprint
You have an AI idea and no evidence either way. In two weeks we build it against your real data and tell you what we found, including the case where what we found is that it isn't worth building. You keep the prototype and the write-up either way.
- The idea has been discussed for months and never tested on real data
- You have the data but don't know whether it's good enough to work from
- Someone needs a decision backed by more than a vendor demo
The first two weeks, concretely
We front-load the parts that reduce risk: a working deployment path, and the piece of the problem most likely to be wrong.
A conversation and a written scope
- One technical call with the engineers who would do the work
- A short document: what we understood, what we'd build first, what we're unsure about
- An estimate as a range, with the specific unknowns that would narrow it
Access, environment, first merge
- Repository access, accounts, and a local setup that works for everyone
- A pipeline that builds and deploys to a staging environment
- Something small merged and deployed, to prove the path end to end
The risky part first
- We build the piece most likely to be wrong, not the easiest one
- The plan gets revised against what we learned actually building it
- You see a running version and tell us where we misread the problem
A weekly rhythm you can plan around
- A demo of what's running, every week, on the same day
- A written update: shipped, in progress, blocked, changed
- Direct access to the engineers, in your channel, not through a manager
How we'll actually communicate
Remote, mostly async
We work distributed and write things down. We commit to a window of overlap with your team's hours for anything that genuinely needs to be live.
In your channel
A shared Slack or Teams channel with the engineers in it. Questions go to whoever knows the answer.
Your process, not ours
Your repo, your board, your review standards and definition of done. We adapt to it rather than running a parallel track.
Bad news early
If something has slipped or an approach isn't working, you hear it that week, with options attached.
What you own, from day one
An engagement should be easy to end. Everything we build lands in your accounts as it's built, so leaving is a conversation rather than a migration project.
- All source code, in your repositories, from the first commit
- Full intellectual property in everything we produce for you
- Cloud accounts, domains, and third-party services in your own name
- Credentials and access: we hold nothing you can't revoke
- Architecture notes, runbooks, and setup docs, kept current as we go
- The right to end the engagement with notice and walk away with all of it
The things people ask before signing
If yours isn't here, ask it on the first call. We'd rather answer it early.
Two ways. Discovery and a first phase can be fixed-price, because the scope is written down and small. Longer work is time-based per sprint, because fixed-price on a moving scope just moves the argument to change requests. We'll tell you which one we think fits before you ask.
You do, entirely, from the first commit. Work happens in your repositories and your cloud accounts. There's no handover migration at the end because nothing was ever held on our side.
You give notice and we stop. Before we do, we finish or safely park work in progress, write up where things stand, and walk your team through it. Nothing in a contract with us is designed to make leaving expensive.
Yes. Your first call is with a senior developer, and that same person is in your channel and on your pull requests afterwards. We don't run a separate sales team, so there's nobody to hand you over to. If a project needs a specialist outside what we do well, we introduce them by name and stay accountable for the work.
It's a real trade-off, so here's the honest version. You get direct access, no communication loss, and consistent judgement across the whole system. What you don't get is the ability to double the team next month. We keep at least two people briefed on every system we build, everything runs in your accounts so nothing depends on us being reachable, and if a project needs more hands than we have, we say so at the start rather than in month three.
That's a large part of what we do. We join your standups, your board, and your code review, and we take ownership of areas rather than picking up loose tickets. Reviewing your engineers' work and having ours reviewed by them both work fine.
It isn't an event at the end. Docs and runbooks are written as the work happens, code is reviewed for whether a new person could read it, and near the end we run sessions with whoever is taking over, then stay available for questions for an agreed period.
Yes. Send yours and we'll sign it or come back with specific redlines. We can work inside your access controls, use your device policies, and complete security questionnaires.
We're based in Bengaluru, India, and default to async. For US clients we keep a fixed daily overlap window, typically into early afternoon US Eastern, and it goes in writing per engagement, along with incident-response coverage. You'll never wait a full day for an answer.
Daily, and in AI-native editors rather than as a novelty on the side. It speeds up scaffolding, tests, migrations, and refactors, which is most of why our timelines are shorter than they would have been a few years ago. It doesn't get to decide architecture. A model will happily produce something plausible for a system it doesn't understand, and catching that is exactly what a decade of doing this buys you. Nothing reaches a pull request that the engineer sending it can't explain line by line.
Nothing. One call, and a short written summary of what we understood and what we'd suggest, including if what we'd suggest is that you don't need us.
Ready to test the process?
The first call is the process in miniature: a conversation, then something in writing.