Products, not projects
Ours to keep and ours to answer for.
- We ship it, run it, and keep paying its bills
- Fixes and improvements have no end date
- The person who wrote it reads the support mail
Independent product studio
A small studio that builds and runs its own products.
We pick the problems, own the architecture, write the code, and stay on the hook long after the first release. Self-funded, and small by choice.
Nobody sets the roadmap but us. There is one narrow exception, and it is written down below.
Build
Small, sharp software we own end to end: the idea, the architecture, the code, the pricing, and the support inbox.
One team, problem to production
No handoff between deciding and building.
- Product, design, and engineering in the same heads
- Whoever chose the tradeoff has to live with it
- Nobody hands a decision off to whoever has to make it work
Open where we can be
The parts that are not the product go out.
- Tools, libraries, and design systems on GitHub
- Write-ups of what worked and what did not
- What we learn on one product goes into the next
Names go up here as products reach people. We would rather show something working than announce something coming.
Studio
Self-funded and self-directed. Three habits keep it that way.
We choose the work
The studio pays for itself, so we decide what to build and when to stop. No outside roadmap, no growth number we did not set ourselves.
Small on purpose
Few products, and no more people than they need. A system small enough to hold in one head is a system we can still change in a year.
Boring where it counts
Proven stacks and plain architecture, with no dependency we could not maintain ourselves. Novelty belongs in the product; the infrastructure stays dull.
What we build with
The default kit. It changes when a product needs something else, not because something new turned up.
- Swift
- Kotlin
- TypeScript
- Go
- React
- React Native
- Node.js
- PostgreSQL
- AWS
- Cloudflare
Outside work
A few engagements a year, in the one thing that sharpens the studio rather than pulling it apart.
Technical due diligence
Across products and infrastructure, for people about to bet on one.
- Architecture, code, and infrastructure, read as they are
- Scaling limits, security exposure, and running cost
- The debt and key-person risk a demo will not show
- Written findings, ranked by risk and effort
Read-only: we change nothing and the findings are yours. Priced per engagement after a scoping call. If it is not a fit, we say so in the first conversation.
Questions
What are you building right now?
Software we want to use ourselves, in areas we already know well. Names and links go on this page when there is something worth using, not before. Email us if you want to hear when that happens.
Do you build software for other people?
No. We do not take briefs and we do not staff teams. Building for ourselves is the whole point, and it is what keeps the products good.
Then what is the outside work?
Technical due diligence, across products and infrastructure. We read the system, talk to the people who built it, and write down what we find. Most run two to four weeks. We take a handful a year, and only when they do not pull the studio off course.
Is any of it open source?
Some of it. Tools, libraries, and the design system this site runs on are public under github.com/sixlab-co. Product code stays ours.
Where are you?
Europe, and remote-first. We work with people anywhere in the world. Async by default, with calls when they earn their place.
Contact
Write to us if you are curious about what we are building, want to know when something ships, or have a system you need read. We reply within 2 working days, and there is no follow-up sequence.
hello@sixlab.co