Who you would be working with
Setu means bridge. We run a services practice and our own products at the same time, deliberately — each keeps the other honest. Building products for a market teaches things client work alone does not, and a team that still sees how a dozen organisations genuinely work does not design for an imaginary one.
Engineering ethos
These are the commitments that shape what we build and how we report on it. Each one carries the practice that makes it checkable, because a principle you cannot verify is marketing.
Rigorous technical planning
We give ranges and say what would narrow them. A single confident number this early is a guess in a suit — it survives until the first unknown, then costs you the schedule and the trust at the same time.
Every estimate ships with the assumptions that would move it.
Total delivery transparency
A slipped date raised in week three is a scheduling problem. The same news in week ten is a crisis. We would rather have the uncomfortable conversation while it is still cheap to act on.
Increments deployed every two weeks, so slippage is visible, not reported.
Maintainable code that lasts
Clear service boundaries and a schema that tolerates change outlast an elegant abstraction only its author can safely modify. We use well-understood databases and frameworks for anything load-bearing, and keep novelty where failure is cheap.
Dependencies are argued for, not added by default.
You own 100% of the IP and code
Repositories, cloud accounts and documentation are in your name from day one. Nothing runs on infrastructure you cannot see, and nothing switches off if you stop working with us. Leaving should be uneventful.
Source, schema, runbooks and infrastructure handed over as standard.
Our story
Setusphere began as a services company, taking on whatever clients needed built. That work paid the bills, but it also put us inside other people’s organisations for long stretches — close enough to see which problems were genuinely hard and which had simply never been anyone’s job to fix.
The pattern that kept recurring was administrative: capable people spending hours a week on coordination that software should have handled. Rather than write another proposal about it, we funded the tooling ourselves and became responsible for operating it. Building products for a market — pricing them, supporting them, living with their defects — teaches things that client work alone does not.
We kept both halves. The services practice benefits from people who have carried a product through its unglamorous second year, and the products benefit from a team that still sees how a dozen other organisations actually work.
Stack ecosystem
Boring where it is load-bearing, current where it earns its keep. Select a layer to see what we reach for and the job each part is actually doing.
Interfaces built to be extended by your team, not just delivered to it.
React
Component architecture
TypeScript
Types across the boundary
Tailwind CSS
Design tokens, not ad-hoc CSS
TanStack
Routing and data layer
React Native
iOS and Android from one codebase
Vite
Build and dev tooling
Boring where it is load-bearing. The data model is decided before the first migration.
Node.js
Application services
Python
Solvers and pipelines
PostgreSQL
Primary datastore
Redis
Queues and caching
REST & GraphQL
Versioned interfaces
Zod
Validation shared client and server
Environments recreated from source, with a pipeline that builds the same artefact twice.
AWS
Primary cloud
Docker
Reproducible runtime
Kubernetes
Orchestration and scaling
Terraform
Infrastructure as code
GitHub Actions
CI/CD gates
Vercel
Edge delivery
Model features shipped behind an evaluation harness, so quality is measured rather than demoed.
Claude API
Reasoning and extraction
pgvector
Retrieval over your corpus
RAG pipelines
Answers traceable to source
Eval harnesses
Regression suites on every change
scikit-learn
Forecasting and scoring
Human review
Approval on anything irreversible
How we operate
Delivery practices that stay in place when a deadline tightens — which is the only time they matter.
No commit reaches a main branch unread. Review is for the decision and its blast radius, not for style — that is what the linter is for.
Types, lint, tests and performance budgets run on every push, and a red pipeline blocks the merge rather than generating a notification someone dismisses.
Each one deployed and demoable, in your repository from the first commit. Progress is something you can open, not something you are told about.
Runbooks, on-call documentation and a tested restore path are part of the work, not a favour at the end of it.
No account managers in between. You speak to the engineers who will make the decisions on your project.
We reply within one working day.
