Skip to content
E—02Embedded engineering7 roles available

Our engineers,
inside your team.

Dedicated engineers and designers working in your stack, your standups, and your repository. Capacity without a hiring cycle, under our review discipline. Each allocation is covered by the same governance as a full programme: a named engagement lead, weekly written reporting, and senior review on every change.

Engagement recordE—02
ShapeMonthly · dedicated allocation · your process
UnitMonthly allocation per engineer
Minimum3 months
ProcessYours
ReviewOurs, on top of yours
Ends withDocumented knowledge transfer
§ 01What you are actually buying

Named people,
not a queue.

Most staffing arrangements sell you availability. This one sells you a specific engineer, with a name you can put on a standup invite and a review discipline that arrives with them.

01

A named engagement lead accountable end to end

02

Weekly written reporting and a defined escalation path

03

Formal change control and senior review on every change

0
Hiring cycles to wait through

An engineer starts inside a week of the brief, subject to availability.

2
Engineers on every change

The author, and a second reader before merge. Our standard, in your repository.

3
Ventures we run ourselves

Our engineers have carried on-call for products we own.

30d
Notice, either direction

With a written handover, so nothing depends on us staying.

§ 02Roles available

Seven roles.
One standard.

Embed one engineer or a small pod. Mixed pods are common — a backend engineer and a designer often move a roadmap further than two of either.

R—01React, Next.js, TypeScript

Frontend engineering

Interface work that holds up under real data. Component structure, state boundaries, accessibility, and the empty and error states most teams postpone.

R—02Node, Python, Postgres

Backend engineering

Data models, service boundaries, and API contracts. Migrations written to run twice without damage, and queries reviewed against production shapes.

R—03Feature ownership end to end

Full-stack engineering

One engineer carrying a feature from schema to screen. Best when your roadmap is wide and the handoff cost between specialists is what is slowing you down.

R—04Android, cross-platform

Mobile engineering

Release trains, store review cycles, offline behaviour, and device fragmentation. We ship Aurelia on Google Play, so this is not theory.

R—05Retrieval, extraction, evaluation

Applied AI and ML

Grounded assistants, extraction pipelines, and evaluation harnesses. Cost and latency budgets set per call path before rollout rather than after the invoice.

R—06Infrastructure as code, CI/CD

DevOps and platform

Reproducible environments, pipelines a non-author can run, observability configured before launch, and a restore path someone has actually tested.

R—07Product design, design systems

UI and UX design

Interaction structure, design tokens, and specifications engineers can build from without guessing. Design that ships, not decks that get admired.

§ 03How onboarding works

Four steps
to a productive engineer.

The sequence is fixed because the failure mode is predictable. Engineers dropped into a codebase without reading it first produce work that has to be undone in month two.

01

Brief and match

Week 0

You describe the stack, the sprint cadence, and the gap. We name the specific engineer we would put on it and share what they last worked on. If we do not have the right person free, we say so instead of substituting a nearest match.

  • Named engineer
  • Allocation start date
  • Written scope of the gap
02

Access and read

Days 1–3

Repository, environment, documentation, and whichever channel your team actually argues in. The engineer reads before writing and returns a short note on what looks fragile, what is undocumented, and what they would not touch yet.

  • Access checklist
  • First-read note
  • Local environment running
03

First increment

Week 1–2

A small, real change taken all the way through your review process and into production. The point is to test the pipeline end to end while the stakes are low, not to look busy in the first sprint.

  • Merged change
  • Review loop verified
  • Deploy path walked
04

Steady state

Ongoing

Full sprint load under your process, with our internal review sitting on top of yours. One monthly note covering what shipped, what slipped, and what we think you should fix next.

  • Sprint participation
  • Second-engineer review
  • Monthly written report
§ 04What it costs

One rate,
per engineer, per month.

The rate depends on role, seniority, and how much of the engineer's month you hold. We state the number in the first reply to a brief rather than after three calls. Everything below is the structure around it.

Unit
Monthly allocation, per engineer

One rate per engineer per month for an agreed share of their time. Not hourly, not per ticket, not per story point.

Minimum term
3 months

Anything shorter is spent on comprehension. You would be paying for the ramp and leaving before the return.

Notice
30 days, either side

Enough time for a handover that leaves your team able to continue the work.

Recruitment fee
None

There is no placement fee, no conversion fee, and no charge if you later hire someone directly instead.

Overheads
Carried by us

Equipment, leave, insurance, and internal review time sit inside the allocation rather than arriving as extras.

Working hours
IST, with agreed overlap

A fixed overlap window with your team is written into the engagement, including standup time.

Ends with knowledge transfer

The handover is part of the price, not a separate contract

Architecture notes, decision records, and runbooks live in your repository from week one. The final month includes walkthrough sessions with whoever inherits the work. If our leaving would hurt you, we built the wrong thing.

  • Documentation written in your repository, not ours
  • Decision records naming the option we rejected
  • Walkthrough sessions with your engineers before exit
  • No transition fee and no lock-in clause
§ 05The standard that travels

We run the software
we recommend.

Three products are ours. We run their releases, their infrastructure, and the consequence of every shortcut taken in them. That is where the operating standard below came from, and it is what an embedded engineer brings into your repository.

V—01Beta

Aurelia

Your network, with a memory.

Relationship intelligence · B2B SaaS

V—02In development

Voyazio

The backbone of travel business.

Travel infrastructure · Vertical SaaS

V—03In development

AxleOne

Powering the backbone of Bharat.

Logistics infrastructure · Fintech

01

Reviewed

No change reaches production without a second engineer reading it. This applies to our own ventures identically.

02

Reproducible

Environments defined as code. Any engineer can rebuild the stack from an empty account.

03

Observable

Logging, error reporting, and alerting configured before launch rather than after an incident.

04

Documented

Architecture notes, decision records, and runbooks handed over as deliverables, not favours.

05

Accessible

Semantic markup, keyboard paths, contrast ratios, and reduced-motion support treated as requirements.

06

Recoverable

Backups verified by restoring them. A backup nobody has restored is a rumour.

§ 06What we will not do

The four refusals.

Stated before the contract rather than discovered during it. If any of these is a dealbreaker for you, we are the wrong supplier and both of us should find that out now.

01

Volume staffing

We are not a body shop. We will not put ten profiles in front of you and let you pick from résumés. If the requirement is headcount rather than engineering, another vendor is a better fit and we will say so.

02

Unreviewed code

No change our engineer writes reaches your main branch without a second engineer reading it. If your process has no review step, ours travels with the engineer. This is not negotiable, including under deadline pressure.

03

Silent substitution

We will not pull an engineer off your work mid-sprint and drop a replacement in. If someone has to change, it happens at a sprint boundary with an overlap period and a written handover.

04

Knowledge held hostage

Everything the engineer learns is documented in your repository, not ours. When the engagement ends, your team can continue without a transition contract.

§ 07Related records

Read the rest
before you commit.

Embedded engineering is one of three models. If your problem is a bounded build or an architecture call, a different shape will serve you better.

Tell us the gap and the sprint you are behind on

Send the stack, the role you need, and the date it hurts by. We reply with who is available, what they last built, and the monthly rate — including when the honest answer is that you should hire directly instead.

WhatsAppStart a chat