BuildspaceLabs is around ten engineers and designers in India, working remotely with clients here and abroad. We take on few clients at a time, so there is no delivery layer between you and the work.
Aryan and Priyanshu are on your build from the first call onwards — scope, architecture, and the answers to your questions. Write to either of us; neither address goes to a queue.
Director
Aryan runs the commercial side. He is who you talk to about scope, what a build is worth doing, and what we would push back on — and he stays on the project after the paperwork is signed rather than handing you to someone else.
[email protected]CTO
Priyanshu owns the technical side. He makes the architecture calls, writes production code, and reviews everything that ships. A question about how something is built is answered by the person who built it.
[email protected]Your project is never one person's private context. Someone else on the team already knows it, and everything that matters is written into your repository rather than carried in somebody's head.
Running a handful of projects at once means each has more than one person across the scope, the architecture and what is in flight. Cover is a reassignment inside the team, not a restart.
Work goes into a repository you own from the first commit — not into ours, to be transferred at the end. Nothing is gated behind our accounts.
Architecture decisions, environment setup, credentials handling and the reasons behind the non-obvious choices are written into the repository, beside the code they describe.
Each week you get a written note of what changed, what is in progress and what is next. That note plus the repository is what another engineer would need to pick the work up.
What we will not claimA standby bench, a partner network or an on-call rota we have not built. The honest constraint is capacity, not continuity: we run few engagements at a time, so the timing does not always line up. We would rather say that before you sign anything than take the work and stretch.
There are about ten of us. The number that matters to you is the other one — how many builds we run at once, which we keep deliberately low. Everything else on this page is downstream of that.
The same senior attention either way. Fewer places for it to go. A diagram of the idea, not a count of anything.
| Dimension | The usual arrangement | How we are set up |
|---|---|---|
| Who builds it | The team in the pitch hands over to a delivery team | The people who scoped it are the people who write it |
| Getting an answer | Routed through an account manager and back | Same day, from someone who can actually decide |
| Why work gets taken | A bench has to be kept occupied | No bench, so no work taken to fill one |
| When you can start | You are slotted into a queue | Sometimes we tell you we cannot start yet |
The cost of itWe sometimes cannot start when you want to. We will say so plainly rather than put you in a queue and call it a start date.
One written scope, no account manager, your repository from the first commit, and support hours we actually staff.
We agree what is being built and what is not, in plain language, before any code is written. If the scope changes mid-build we say so rather than absorbing it quietly.
No account manager sits between you and the work. The person answering your question is the person who wrote the code.
Code lives in your repository, not ours. You can read it, audit it, and take it to another team at any point without asking us for anything.
Support is Monday to Friday, business hours IST. We do not promise a 24/7 rota we do not staff.
That is why our email addresses sit on the vruoom.com domain. Contracts, invoices and the registered entity behind them are shared in full before anything is signed — earlier if procurement or diligence needs them.
Send us what you are trying to build. We will tell you what we would do, what we would cut, and whether we are the right team for it — including when the answer is no.
Get a build review