Home/Services
Six practices,
one delivery team.
Most projects draw on three or four at once. You get one pod and one project manager who runs it end to end, rather than a brief passed between departments.
Free consultation · reply in one business day
06
Practices under one roof
3–4
Practices on a typical project
01
Project manager, start to finish
3–7 days
From first call to a fixed quote
Where to start
Nobody buys one practice.
Pick the shape closest to what you have. The board shows which practices lead, which support, which you will not need — and the nearest thing we have already built.
Closest thing we have built
SuperSlim, a doctor-supervised medical weight-loss platform. Eligibility screening, a paid video consultation with an MD, an e-signed prescription, subscription billing and pharmacy fulfilment, across six role-based panels on NestJS, React and PostgreSQL.
See the workThe team this needs
A product designer and the lead developer from day one, then two to three developers once the prototype settles. A project manager throughout.
Closest thing we have built
A strangler-fig migration off an old monolith: new work routes through a documented contract while the legacy platform is retired a piece at a time, with no feature freeze.
Read the playbookThe team this needs
A lead developer and a backend developer on the contract layer, a designer as screens move across, and a DevOps engineer while both systems run side by side.
Closest thing we have built
The Airwave Industrial Shopify store. Over 1,000 part numbers cross-referenced to five OEM brands, searchable by Airwave number, OEM number or compressor model. The cart is a quote list.
See the workThe team this needs
A lead developer and a developer in Liquid, a designer on category structure and search, and a project manager whose real job is the catalogue itself.
Closest thing we have built
One codebase, two stores, talking to an API we either built or documented — with the offline behaviour designed up front rather than discovered by a user on a train.
See the workThe team this needs
A lead developer, one to two mobile developers and a designer, with the project manager owning the two store submissions.
Closest thing we have built
Monitoring, then measurement, then the three changes that account for most of the time — rather than the rewrite nobody asked for and nobody can schedule.
See the workThe team this needs
A DevOps engineer alongside a lead developer, part-time, for as long as the numbers keep moving. This is the one shape that rarely needs a full pod.
The six practices
What each one actually does.
Positioning, the scope shapes we see most, what you end up owning — and when we would tell you it is the wrong practice for the job.
Web & Platform Engineering
From marketing sites that load fast on a village 4G connection to multi-tenant SaaS platforms serving thousands of users — built on Laravel, React and Vue, and handed over with the documentation to run them.
Typical scope
- SaaS platformMulti-tenant, role-based panels, billing, and the admin nobody demos but everyone lives in.
- Site with a CMSA site your own team edits without calling us, that still loads on a poor connection.
- Admin over data you already haveA dashboard and a permission model over a database that already exists.
You end up owning
- The application source, in your repository
- A documented data model and role matrix
- Environment configuration for staging and production
- Written handover documentation
- Performance, SEO and accessibility baselines
Not the right call when
The whole requirement is five brochure pages with nothing to edit. We will scope that as a week, not a project.
Mobile Engineering
One codebase where it makes sense, native where it does not. We build apps that behave on a poor connection and ship through a release process your team can actually run.
Typical scope
- One app, two storesA shared codebase talking to an API we either built or documented first.
- A field appUsed where the network is not. It writes locally first and reconciles when the signal returns.
- A companion appA thin app over a platform that already exists, for the two things people do on a phone.
You end up owning
- The app source, in your repository
- Signing keys and store listings in your name
- The release pipeline for both stores
- Push notification and deep-link configuration
- Crash reporting, already wired up
Not the right call when
What you actually need is a fast mobile web page. An app nobody installs is worse than a site that loads.
Product Design
Research-driven wireframes and prototypes before a line of code is written. We design the states nobody remembers — empty, loading, error, offline — because that is where products actually get used.
Typical scope
- A product from zeroResearch, flows, and a clickable prototype you can put in front of a real user.
- A system, not screensComponents, states and rules, so the twentieth screen costs less than the first.
- A review of what existsA usability pass on a live product, with the findings ranked by what they cost you.
You end up owning
- The source design files
- A component library, with its states
- User flows and the research behind them
- A clickable prototype
- Component-by-component handover to the build team
Not the right call when
You already have a designer and a system that works. We build to it and review it, rather than replace it.
APIs & Integrations
The unglamorous layer that decides whether a system holds together. Versioned contracts, sensible errors, and third-party integrations that fail loudly rather than silently.
Typical scope
- A public APIVersioned routes and documentation someone outside your team can build against without asking us.
- One integration, end to endPayments, messaging or a partner system, including what happens when it is down.
- A contract over a legacy systemNew work routes through the contract instead of the old system's internals.
You end up owning
- Contract documentation and a published request collection
- Versioned routes, with two versions live at once
- Signed webhooks, with retry and replay
- Integration credentials, in your own accounts
- An error format a client can actually act on
Not the right call when
One system needs to send one file to another once a night. That is a scheduled job, not an integration programme.
Cloud & DevOps
Infrastructure as code on AWS, GCP or Azure, with automated deployment pipelines and monitoring set up before launch — not after the first outage.
Typical scope
- Environments and a pipelineStaging and production that match, and one command that deploys either of them.
- A migrationOff a single hand-configured server, onto something that can be rebuilt from the repository.
- A performance and cost passMeasure first, then change the three things that account for the bill.
You end up owning
- Infrastructure defined in code, in your cloud account
- A CI/CD pipeline
- Monitoring, logging and tested backups
- A runbook for the failures we expect
- Hardened server configuration
Not the right call when
A managed platform already does it for a fraction of the cost of running your own. We will say so and move on.
E-commerce & Shopify
Custom Shopify themes and headless storefronts for businesses whose catalogue is the hard part — thousands of SKUs, cross-referenced part numbers, B2B quote flows instead of a checkout. Built in Liquid, extended through the Shopify APIs.
Typical scope
- A catalogue of thousandsSearchable by whichever number the buyer happens to have in front of them.
- A quote list, not a checkoutBuyers build a list; you send price and lead time back.
- A migration off a legacy cartWithout losing URLs, customer accounts or order history.
You end up owning
- The theme repository
- A catalogue and collection model you can extend
- Payments, shipping and tax configuration
- Webhooks and any private app we built for you
- Admin training for the people who run the store
Not the right call when
You sell six products and Shopify's own theme already does it. We will help you set it up and stop.
Getting started
What happens in week one.
Every engagement opens the same way. Here is the whole of it, including the half that is your homework.
Day
What we do · what lands
From you
Day 01
Kick-off
We meet the people who will use it, not only the people paying for it. What breaks today gets mapped, and we agree who signs off on what.
From you
One hour, and the person who actually makes the decision.
Day 02
Access and audit
Repository, hosting, analytics and domain access reviewed, and the existing system walked end to end. Whatever we are not yet sure about gets written down rather than assumed.
From you
Read-only access, or the name of whoever holds it.
Day 03
Scope on one page
The requirement list, ranked, with what is in phase one and what is explicitly not. Most projects change shape here, which is far cheaper than changing shape in month four.
From you
A decision on anything we flag as ambiguous.
Day 04
Approach and risks
A data model sketch, the integration list, and the three things most likely to go wrong with what we would do about each. Written down, not presented.
From you
Nothing.
Day 05
Timeline, quote, team
A fixed timeline, a fixed quote, and the names of the people who will be on your pod. Nothing here is a range that quietly widens later.
From you
Yes, no, or one more question.
Discovery runs 3–7 days depending on how many systems it touches. The consultation that starts it is free.
Engagement models
Three ways to engage.
Same team, same process. What changes is the commitment, how scope moves, and what ends it.
| Quoted after discoveryFixed-scope project | Monthly retainerDedicated team | From go-live onwardSupport & maintenance | |
|---|---|---|---|
| Best when | The requirements are settled and the outcome is clear. | The roadmap is longer than any one project, and priorities will move. | The product is live and has to stay that way. |
| How it is priced | One quote, fixed at the end of a three-to-seven-day discovery. | A monthly retainer for the pod, sized after the same discovery. | Monthly, from go-live onward, after a handover audit. |
| The team you get | A pod drawn from the six practices for the length of the build: project manager, lead developer, two to three developers, a product designer. | The same pod, working only on your roadmap, month to month. | A named engineer who already knows the codebase, and the project manager who ran the build. |
| When scope changes | A change request against the fixed quote, priced and agreed before anyone starts. | It is re-prioritised into the next sprint. The cost does not move; the order does. | Small changes sit inside the retainer. Larger ones are sized and quoted separately. |
| How you see progress | A working demo on a staging URL at the end of every sprint. | Sprint demo, plus a roadmap review each month. | A monthly report: what changed, what was patched, what we are watching. |
| What ends it | The scope ships and handover is signed off. | Notice, month to month. | Notice, month to month. |
| What you own | Code, repository, infrastructure and documentation, in your accounts. | Code, repository, infrastructure and documentation, in your accounts. | Code, repository, infrastructure and documentation, in your accounts. |
Scroll the table sideways →
A standard engagement team
One team, one roadmap, one dedicated project manager — from the first call through to post-launch support. Practices are drawn on as the work needs them, not billed as separate vendors.
How we quote
- Nothing is quoted before discovery. A number given before we understand the system is a guess with a decimal point on it.
- The quote is fixed against the scope document, not against a conversation.
- Free consultation, and a reply within one business day.
Before you commit
The questions that decide it.
The ones that come up on every call. Answered here so they do not have to be the first thing you ask.
You own all of it.
The repository, the cloud accounts, the domain, the design files, the documentation and the store listings are in your name from the first week — not transferred at the end if everyone is happy. There is no lock-in we cannot unwind, because we are optimising for your fourth year rather than our first invoice.
On a fixed-scope project the change is written up, priced and agreed before work starts, which is how a fixed quote stays fixed. On a dedicated team it goes into the next sprint and something else moves down — changing your mind is the model there, not an exception to it. Either way it surfaces at a sprint demo, not in an invoice three months later.
Yes, and it is usually the better outcome. Same repository, code review on every change, staging from the first sprint, and your process rather than ours imported wholesale. We would far rather your team can maintain what we build than be the only people who understand it.
That is the case we design for. Tools with long support horizons and large hiring pools, infrastructure in code, data in open formats, contracts documented, and a handover that includes training for the people taking it on. Nothing you need to run the software lives only with us.
No. We build to your system and review it rather than replace it. We will ask for the states that tend to get skipped — empty, loading, error, offline — and if they do not exist yet, that is a short piece of design work rather than a stage.
Common, and much of what the APIs practice actually does. We map it by observation, put a documented contract in front of it, route new work through the contract rather than the internals, and then the old system can be replaced a piece at a time instead of in one release everybody dreads.
They are the default, because a team that knows one stack deeply ships faster than a team that knows five shallowly. We also work in NestJS, Node, Vue, Next.js, Flutter and React Native. The rule is tools with long support horizons and a large hiring pool, so we will say so when your problem wants something else.
Launch is a stage in the process, not the end of it. Maintenance, security patches, tested backups and performance work run under a support agreement, with a support channel that has a person on the other end. Most clients are still with us years after the first release.
Have a difficult problem?
Let’s turn it into a product worth building.
Free consultation · reply in one business day · +91 91733 99077