Our process - How we work
Most of our work starts as someone else’s stuck problem. The pattern is usually the same: the data already exists, the system of record is fine, and nobody can get an answer out of it. So we spend the first phase finding out what the problem actually is, and only then decide what to build.
Discover
We start by watching the work being done, because the brief and the problem are rarely the same thing. What someone asks for is a portal. What is actually wrong is that a trained operator is the only path to an answer, and the client is never on the other end of it.
At a fine art logistics group this took two passes. The first found the obvious problem — the records were locked inside an ERP with no web interface. The second found the one that mattered: half the catalogue was described in a single word, so even a perfect search box would have returned nothing. A bronze of a mounted rider was catalogued as Statue.
The output of this phase is a written argument for what to build and what not to build. Saying which alternative we rejected, and why, is part of it — an approach nobody can argue against is usually one nobody has thought about hard enough.
Included in this phase
- Working sessions with the people doing the job
- Data and schema review
- Retrieval quality baseline
- Written options, with the rejected ones
- Proof of concept
- Acceptance criteria agreed up front
Build
Architecture is held in the United States and engineering runs from our team in Vadodara. That is the whole model, and it is deliberate: the person accountable for the design sits in your timezone, and the people building it are a team that has worked together for years rather than contractors assembled for your project.
There is no account manager in the middle. On the engagements we are proudest of, the client’s engineers talked directly to ours — at Atlassian a two-person team worked straight with their security and infrastructure stakeholders on a change to the storage path of a multi-tenant cluster. A layer of translation would have made that slower and more dangerous, not safer.
We carry DevOps and on-call ourselves rather than handing an un-owned system back at the end. Where a client has no in-house engineering team, that is not an add-on; it is the only honest way to ship something they will still be running in two years.
The two-person team operated with clarity, autonomy, and rigor, matching the standards we expect internally at Atlassian. It was plug-and-play execution with zero overhead on our end — exactly what we needed.
Deliver
Most of what we build goes live underneath a business that cannot stop. A finance organisation does not agree to pause the close; a retailer does not re-platform in November. So cutovers are designed to be reversible and rehearsed rather than brave.
For a global apparel brand we replayed three times peak traffic against the new stack before anything moved, then switched over at two on a Sunday morning with a twenty-four minute read-only freeze. For a fintech we verified every migrated dataset by checksum against its source rather than by sampling, because the job is not moving the data, it is convincing the finance team the numbers still tie out.
Then we hand over properly. At a fine art logistics group the team kept delivering for more than a year after our architect rolled off the engagement, which is the only real test of whether work was built to be owned by someone else.
Included in this phase
- Rehearsal. Load and failure replayed against the new system before anything moves, so the cutover is the least eventful part of the project.
- Verification. Parity proven mechanically — checksums, not spot checks. The people who have to sign off get evidence rather than reassurance.
- Handover. Runbooks, on-call and the design decisions written down, so the system survives our leaving. We would rather be re-hired than depended on.
Our values - Balancing reliability and innovation
A small firm competes on judgement, not on capacity. These are the working rules that decide what we do when a project gets difficult, which is the only time principles are worth anything.
- Diagnose first. The stated problem and the real one differ often enough that building before understanding is the most expensive mistake available. We would rather lose a week than solve the wrong thing.
- Leave the system of record alone. Replacing what runs the business is rarely what the problem requires. Most of our work sits alongside an ERP or a warehouse system that stays exactly where it is.
- Measure, don’t assert. If the question is whether something is fast enough or correct enough, the answer is a number from a harness we built, not an opinion.
- Small teams, direct lines. Your engineers talk to ours. Two people who understand the problem beat a larger team routed through an account manager.
- Say what we rejected. Every recommendation comes with the option we turned down and the reason. An approach with no discarded alternative has not been thought about properly.
- Build to be handed over. Documentation, runbooks and on-call from the start. The measure of the work is whether it still runs well once we are gone.