Deliberate choices. Stated up front.
We've made deliberate decisions about what we use and how we work. We'd rather explain them than pretend they don't matter.
Depth beats breadth.
Twelve years in this ecosystem means we know where the rough edges are, what's stable, and what to avoid. After 12 years, we can ship faster and produce more maintainable code in C# than we ever could by context-switching into something we only use occasionally.
C# .NET 10+ as the backbone
ASP.NET Core is among the fastest web frameworks on any benchmark you care about. EF Core handles 95% of database access elegantly; we drop to raw SQL for the rest. Runs on Linux, Windows, macOS. Deploys to anything from a R200/month VPS to Azure App Services or Kubernetes. Microsoft funds it for the long term.
B Blazor for the web
Rich, interactive web UIs in C# instead of juggling React, Vue, or whatever this year's JavaScript framework is. For business apps — which is most of what we build — it ships faster, has fewer moving parts, and one developer can deliver what would otherwise need a frontend specialist and a backend specialist.
M .NET MAUI for native
One codebase, native rendering on Android, iOS, Windows and macOS. For business-grade mobile apps, MAUI is the right call 80% of the time. For consumer flagship products where the UI IS the experience, we'll be honest and recommend a native specialist.
DB PostgreSQL by default
Free, fast, mature, runs anywhere, SQL standard support is excellent. SQL Server when you're in the Microsoft ecosystem. SQLite for embedded scenarios or small single-user apps.
JS JavaScript, sparingly
HTML, CSS, JavaScript used where needed — not for their own sake. We don't push SPAs when a server-rendered page will do, and we don't add a build pipeline to a five-page brochure site.
/ What we don't use
Not Node, Python, Ruby, Go, Rust, PHP, or the dozens of frameworks orbiting them. Not because they're bad — but because depth beats breadth. If your project genuinely needs a stack we don't work in, we'll say so up front and help you find someone who does.
Five rules. Stated up front.
Plan first, build second
For anything non-trivial, we propose an approach in writing before we touch code. This isn't bureaucracy — it's how we make sure we're solving the right problem, and how you spot a wrong direction before we've spent two weeks going there.
Rough first, polish second
We build in passes. First: prove it works end-to-end. Second: clean up the messy parts, add the edges. Third: polish. Faster than writing perfect code on the first try, and it gives you something to react to early.
You talk to the engineer
Always. No tickets routed through account managers, no status reports written by someone who didn't write the code. WhatsApp, email, calls — whatever's easiest.
We tell you when you're wrong
If you're about to make a technical decision that's going to hurt in 12 months, we'll say so. We'd rather lose a small fight now than build something we both regret.
We don't pad estimates
When we say two weeks, we mean two weeks. When we don't know, we say so and propose a small spike to find out. If we hit a problem, you hear about it the day we hit it — not when we miss the deadline.
You own everything
Code in a Git repo you own. Deployment instructions written down. Documentation good enough that the next developer can pick it up. We don't build lock-in.
Real engineering. Real conversations.
The "cafe" in the name is deliberate. You ask a question, you get an answer. You don't pay for the office.