Small team. Systems that cannot fail.
We are an engineering firm in Hyderabad whose software runs inside a state legislature during live sessions. The team is small enough that one engineer owns a whole surface, and the standards you would be held to — security, performance, delivery — are published on this site, so you can read them before you apply.
Why this is not the same job elsewhere.
Most engineering roles are described by their stack. Ours is better described by what happens when it breaks — which is the part that makes the work worth doing.
It runs where failure is visible
A digital pass system operating inside a state legislature during live sessions, with a scan at the gate and no paper fallback. If it is down, people notice within a minute and it is on the record.
The case studyThe AI has to work in Telugu, on a bad connection
Speech and language models in production for Indian languages, with a human gate before anything consequential becomes an official record. Benchmarks are not the job; the transcript being right is the job.
The case studyYou own a system, not a ticket queue
Teams here are small enough that one engineer holds a whole surface — the API, the console the operators live in, and the reason it is shaped that way. Nobody hands you a spec written by someone who has never met the user.
The standards are published
Our security controls, performance handbook and delivery method are on this site in public. You will be held to them, and you can read all of them before you apply.
How we work, in publicFour habits, not four adjectives.
Every line here is visible somewhere else on this site — in a case study, in the controls register, or in the list of clients we tell to hire somebody else. That is the test we applied: if a candidate could not verify it, it did not go on the page.
Decisions get written down before code exists
Every engagement produces an architecture note in plain language. You will write them, and you will be asked to defend the trade-offs — which is a far better use of a review than arguing about formatting.
A person signs off anything consequential
We do not ship AI output straight into an official record. Building the gate, the audit trail and the correction path is part of the work, not an afterthought bolted on for compliance.
We say what we cannot do
We publish the cases where a client should hire somebody else, and we state that we are not ISO 27001 certified yet. The same directness is expected internally: an estimate you do not believe is worse than no estimate.
The people who scope the work build it
There is no separate delivery centre that inherits a project after the pitch. If you sat in the discovery, you are on the build — which is also why we are careful about what we take on.
Three conversations, a paid exercise, and a decision in a week
Only what we are actually doing.
Short, because everything on it is real. We would rather lose a candidate to a longer benefits list than win one with a promise we cannot keep in month two.
Work on named, referenceable systems
Everything we ship is attributed on this site with the client named. Your work is something you can point at in an interview ten years from now, not an NDA-shaped hole in your CV.
An office in Gachibowli, and hours that respect the system
We are a Hyderabad team that works together in person. Support windows are scheduled around when a system is genuinely used rather than around office hours — and when that means an unusual week, it is planned and it is compensated, not assumed.
Health cover from day one
Health insurance for you, in place from your first day rather than after a probation period.
Time to learn, on the clock
The performance and security handbooks on this site were written during working hours by the people who use them. Learning that improves the work is part of the work.
A named first project, agreed before you sign
You know what you are joining to build before you accept. No bench, no "we will find you something", no reassignment in week two.
5 roles. Each one owns something.
A role stays on this page only while we would genuinely make an offer for it. If a listing is here, the budget and the first project are already agreed.
Own a surface end to end — the API, the operations console the client’s team lives in eight hours a day, and the decisions behind both.
This is not a ticket queue. You sit with the people who use the system, write the architecture note before the code exists, and then build the surface they will live in — schema, API, screen, error states and the audit trail that makes the work reviewable.
The work is production from early on: institutional workflows, operations consoles, and the unglamorous behaviour that decides whether a system is actually adopted. You will ship weekly against a named client, and you will still be answering for it after go-live.
- A production surface used by a named client, from schema to screen
- The operations console: the unglamorous screen that decides whether a system is actually adopted
- APIs, migrations and data integrity — including the cases nobody put in the spec
- Offline and low-bandwidth behaviour, because a gate does not always have signal
- Auth, roles and the audit trail behind consequential actions
- The architecture note that explains why it is built this way, and the reviews that keep it honest
- On-call for the surface you own, with support windows scheduled around when it is actually used
- TypeScript, React and a server-side runtime you are fluent in
- You have taken something to production and then maintained it
- You can write a paragraph explaining a trade-off to a non-engineer
- Comfort with the boring parts: migrations, audit trails, error states, logs
- You can read a running system and say what will break under load, not only what looks clean in a PR
Not for you if: You want to work only on greenfield features and hand off the operational tail to somebody else.
Nothing here fits?
We hire ahead of a role when someone is clearly right. Send what you have built, tell us which of our systems you would want to work on and why, and skip the cover letter — one honest paragraph beats a page of adjectives.
The questions worth asking first.
- Is this remote?
- No. We are a Hyderabad team and the work happens together in Gachibowli. Being in the room is a large part of how a small team stays accountable end to end, and much of our client work is on site in ways remote cannot cover. We would rather say this plainly than have you discover it in the offer conversation.
- Do you pay for the exercise?
- Yes. It is scoped to a few hours, it is drawn from real work rather than invented, and we pay for your time on it whether or not we make an offer. An unpaid multi-week take-home filters for people with free evenings, not for people who are good at this.
- What happens if I do not get the role?
- You get written feedback, and it will be specific. If the gap was experience rather than ability, we will say what we would want to see and you are welcome to come back.
- How junior can I be?
- Most roles ask for around two years; the adaptive-learning and attention roles ask for three in a similar line of work, because the systems are live from early on. If you are earlier than that and have shipped something real, write anyway and point us at it.
- What does the first month look like?
- You have a named project before you sign, so week one is that project rather than an onboarding queue. You will read the architecture notes for the system you are joining, sit in on a client conversation early, and ship something small to production inside the first fortnight.
- What do you actually assess?
- Whether you can take an ambiguous problem, decide something, and explain why. Almost every failure mode we have seen in this business is a decision nobody wrote down — not a missing algorithm.