← Back

Common questions, honest answers

The things people usually ask before we start working together.

Working with us

Two people with backgrounds spanning software engineering, academic research, and data science. We’re small by design: you work directly with the people doing the work.

It varies. Some projects are a few weeks — build an MVP, integrate a model, ship it. Others run for months, where we operate and evolve a system over time. We usually start small and extend if the fit is right.

Rarely. We do our best work as an independent unit — owning a problem and delivering outcomes, not filling a seat on your org chart.

Finland. We work with clients across Europe and beyond.

Depends on current load. Reach out and we’ll give you a real answer.

Technology

We pick what fits the problem. We’ve shipped production systems in TypeScript, Python, Go, Rust, C#, Clojure, and Elixir — usually backed by PostgreSQL and deployed with Docker to the simplest infrastructure that makes sense.

Modular monolith. PostgreSQL for literally everything — queuing, caching, pub/sub, file storage, vectors, geospatial. No Kubernetes, no deep cloud orchestration. A VPS or a simple container runtime. It’s good enough, and “good enough” ships.

Yes — whether it’s unattended AI-generated code or a 30-year-old system. We start by establishing solid tests and verification before touching anything deeper. You have to understand a system before you can safely change it.

Commercial

Fixed fee for defined scopes, or a monthly retainer for ongoing work. Most projects start in the low five figures. We don’t take equity.

What we build for you is yours. We keep ownership of our own internal tools and methods. Standard NDA before any work begins.

Everything is built so your team can own it. Clean handoff — documentation, access, context. If you want us around after that, we offer lightweight retainers to keep things healthy without a big commitment.

Yes, when it makes sense. We run hands-on workshops on AI-augmented development and working effectively with the tools that are changing how software gets built. This tends to land best after we’ve built something together — shared context makes the teaching stick.

Didn’t find what you were looking for?

Get in touch →