For founders who want to picture what working with us actually looks like.
Jump to section
Studio About Empyreal Infotech
A small, senior engineering studio. Built around one architectural call.
Empyreal is twelve full-time senior engineers, two offices, and one rule we’ve never broken. The diagram, the trade-offs, and the call get made on paper before the first commit. It’s a small discipline. It’s the difference between code that lives two years and code that lives ten.
24hreply, from a senior
100+projects shipped since 2019
Senioronly, on the spine
You’re probably not reading top to bottom.
Most founders skim this page non-linearly, looking for the two or three sections that answer whatever brought them here. Here’s the table of contents, with a one-line read on what each section is for.
For the CTO who wants to read our actual reasoning, not our marketing about it.
Jump to sectionFor the buyer who wants to see what we learned before signing a contract.
Jump to sectionFor the founder who wants to know who’s actually writing the code.
Jump to sectionFor everyone, but especially the founder choosing between three studios this week.
Jump to sectionFor the questions we get asked most often before the first email.
Jump to sectionWhat 12 productive hours actually look like.
One Tuesday in March. London picks up the architecture call from yesterday’s audit. Rajkot ships against last night’s decisions. The handoff is engineered, not improvised, and the founder sees visible progress before lunch.
Mohit opens the founder inbox.
Two first emails landed overnight. Both get a thoughtful reply before 09:00. One is a yes with two questions. One is an honest no, with a paragraph explaining why and what we’d do in their shoes.
Standup with London and Rajkot.
15 minutes, no slides. What shipped last night, what’s unblocked today, what architectural calls need Mohit before lunch.
Architecture review, client A.
Live whiteboard with the founder. We’re choosing between Postgres-on-RDS and Aurora Serverless for a fintech about to onboard 4,000 merchants. We write the trade-offs down. The founder picks. The doc gets committed to the repo.
PR review on the spine.
Six PRs on schema, auth, payments, and infra. Mohit reads all of them. Approves four, asks specific questions on two. The questions are in writing, in the PR, with the trade-off named.
Build sprint, Rajkot.
Eight senior engineers ship against the morning’s architecture calls. Code lands in your repo with the diagram updated and the migration notes attached.
Friday demo prep.
If it’s Thursday, the build candidate gets a 30-minute pre-flight. Clickable, instrumented, measured against last week’s number.
Mohit signs off.
One last pass on PRs touching the spine. Rajkot wraps. Tomorrow’s architecture call is on the calendar, with the founder, with the trade-offs already drafted.
What we mean by “we wrote the trade-offs down.”
An anonymised real call from a Series A fintech we shipped for in 2025. The founder needed merchant onboarding live in 5 weeks. The first instinct was to bolt KYC onto the existing auth service. We didn’t. SPINE-12 / 2025-04-09 — “Where does the KYC boundary live?” Decided and signed by the founder.
Do we put KYC inside the auth service?
Or stand it up as its own service with its own boundary?
4,000 merchants in 6 months.
FCA-aware audit trail. The founder wants to move to PSD3 attestations within 18 months.
KYC inside auth.
Cheaper to ship by 2 weeks. Couples identity and verification. Any future change to KYC vendor (Onfido, Persona, etc.) ripples through auth. Audit-log boundary is fuzzy.
KYC as its own service.
Plus 2 weeks of work up front. Cleaner audit boundary. Vendor swap stays local. Future PSD3 attestations live where they belong. Easier to defend at the next FCA visit.
Option B. We took the 2-week slip.
The alternative was a year-two refactor we’d already done for another fintech. Founder signed off in the call. The diagram and the migration plan are in the repo, dated, with both options preserved so the next engineer reading it knows what we considered.
One doc per spine decision.
This doc lives at /docs/architecture/spine-12.md in the client’s repo. Every spine decision gets one of these. By the time the system goes to production, there’s a folder of them. The next engineer joining the team inherits the why, not just the what.
Three mistakes we paid for. So you don’t have to.
Most studio websites pretend the work has always gone well. Ours hasn’t, and the honest thing is to say so. Three projects where we paid for a decision, and what they taught us. Clients anonymous, lessons named.
We promised a 6-week MVP on a 9-week problem.
An ed-tech founder needed a beta for a fundraise. We took the work without writing down what a 6-week build couldn’t include. Three weeks in, scope and timeline started fighting. We delivered the MVP late by two weeks, and ate the gap. The product launched. The relationship didn’t survive.
What we changed: every scope now has a written “not in this build” list signed by the founder before week one.
We took on a project the founder wasn’t ready for.
A pre-seed marketplace, no paying customer, plenty of design and very little signal. We built the platform. It launched. It never found product-market fit. The founder paid for engineering they didn’t need yet. We’d told them “maybe” when the right answer was “not yet.”
What we changed: about 1 in 3 projects we hear from now, we turn down. Pre-seed without a paying customer is the most common reason.
We treated documentation as a nice-to-have.
A B2B SaaS client’s in-house team inherited the codebase. Six months later we got a panicked email: the team couldn’t explain a decision to a new joiner. The reason was that the trade-off doc didn’t exist. We came back, wrote it up after the fact, and didn’t charge for the time. It cost us a week.
What we changed: spine decisions now ship as a doc in the repo on the day they’re made. Not at the end of the sprint.
The senior bench
Twelve engineers. Same team, project to project.
The team you meet in week one is the team that ships in week six. No analyst chain, no bench filler, no offshore handoff. Four of the twelve, with what they actually ship.
Mohit Ramani
01 · London · Founder & Lead Architect
Reviews every PR that touches the spine. Writes every first reply. Has been in the room for every architecture call since 2019.
Spine review · founder calls · PRs #1 to #11,304
Priya Mehta
02 · Rajkot · Principal Engineer, Backend
Nine years on payments and identity. Built the settlement engine on N1 Payments. Before Empyreal: senior at a UK fintech scale-up.
Postgres · Node · Stripe · Risk modelling
Arjun Patel
03 · Rajkot · Senior AI Engineer
Production RAG, agents, evals. Shipped the matching engine on Chance AI. Before Empyreal: senior ML at a Series B health-AI startup.
LangGraph · pgvector · FastAPI · Evals
Aanya Iyer
04 · London · Senior Frontend Engineer
Reads Figma the way the designer intended, then tells you which decisions in it will fight the architecture three months in. Eight years on Next.js, React Native, Flutter.
Next.js · React Native · Flutter · Design systems
Plus 8 more senior engineers across backend, mobile, AI, and infrastructure — meet the rest of the team.
Ask who’d work on your project
Seven things we won’t do.
The right partner is the one who knows when they’re wrong for the work. Here’s ours, written plainly, so you can decide before the call.
We won’t skip the audit week to win the work.
Even when the brief says “move fast”, the diagram and the trade-offs come first. If that timeline doesn’t fit your fundraise, we’ll say so before the contract, not after.
We won’t put a junior on your spine.
Schema, auth, payments, infrastructure: all senior. If we can’t staff your project with senior engineers, we won’t take it on.
We won’t write code we can’t document.
If the architectural reasoning can’t be written down in plain English, we’re not done thinking. Documentation isn’t after the work. It is the work.
We won’t take a pre-seed build without a paying customer.
You’ll hear “ship the cheapest thing yourself first.” About 1 in 3 projects fall here. We’d rather lose the contract than spend your runway on engineering you don’t need yet.
We won’t add “just one more thing” without a written trade-off.
Scope changes get reviewed in writing, with the cost named, in front of the founder. No silent creep. No surprise sprints.
We won’t take work we’re not the senior team for.
Hardware-first robotics, AAA game engines, regulated medical devices: not our work. We’ll point you to studios who do that better than we do. The honest referral is part of the deal.
We won’t pretend we’ve always got it right.
See the section above this one. The mistakes are real. We keep the lessons next to the rules. If a future client asks us about them, we’ll explain them again.
The 7 questions founders ask before the first email.
The questions that come up most often when someone’s reading this page, deciding whether the studio is the right shape for the project they’re holding.
Mohit Ramani founded the studio in 2019, after three years cleaning up other teams’ production systems. The same brittle architectural patterns kept showing up: schema chosen for the demo, auth boundary written without thinking about multi-tenancy, payments wired without an audit trail. Empyreal opened with one rule: take no build until the architectural calls are made on paper, in front of the founder, before code gets written.
Twelve full-time senior engineers, seven years average experience on production systems. Four in London, eight in Rajkot. No juniors on the spine of your project. No bench filler, no contractor-on-contractor stack. The team that audits your codebase in week one is the team shipping into your repo in week six.
Three integration models. As a senior pod that owns specific surface area, like the AI workflow or the payments rail. As a paired-engineer arrangement, where one of our seniors sits next to one of yours on every PR. As an architecture-only engagement, where we make the calls and your team ships against them. We pick the model in the audit week, with the founder in the room.
Week one is on paper. We read what exists, draw the system as it should be, write the trade-offs down, and make the call with the founder in the room. Only then does code get written. Week two onward is the build. Documentation is the work, not an afterthought. The full sequence is written up in our methodology.
Mohit reviews every PR that touches the spine: schema, auth, payments, and the infrastructure decisions that decide whether the platform stays alive under load. Domain PRs are reviewed by the senior on the project. The founder who answers your first email is the same person signing off on the architecture call and reading the merge requests that matter most.
We tell you, in writing, the same week we see it. Then we offer two paths: extend the sprint at our cost to absorb the slip, or revise the scope with the founder before we resume. We’ve done both. We’ve also walked away from work we couldn’t make right. The walk-away clause works in both directions, and the rest of the commitments are written down in our guarantee.
Yes. Monthly advisory keeps the architecture honest as the company scales. Weekly standups, quarterly architecture reviews, the call before the next round of feature creep. We treat this as the most valuable part of the relationship, because it’s where the year-two bugs would have shown up if we’d left after launch.
Inside the studio
Two cities, one senior bench.
London and Rajkot, sixteen hours of overlap. Your account director goes home with a list and wakes up to it shipped — same senior pod, no overnight hand-off to strangers.
- Senior-only on the spine of every build
- Sixteen-hour working overlap, two offices
- One inbox — Mohit reads the first email himself
The audit week
We draw the system before we build it.
Every engagement opens with a fixed-scope audit week. You leave with a one-page architecture diagram and a signed scope — not a 60-slide deck and an invoice. What it costs is on our pricing page, and what it produced for other teams is in the client outcomes.
If any of this sounded like the studio you’ve been hoping to find, we’d love to hear from you.
The first move is one short email. Mohit reads each one personally, gives it real thought, and writes back inside 24 hours. A kind yes, a kind no, or the one question that decides it. Whichever the answer turns out to be, we’ll try to leave you with something useful.
No pressure, no sales sequence, no “just circling back”. Just one founder, one inbox, one honest reply.