Method
Short loops, clear deliverables, no middlemen.
You talk directly to the people writing the code. We work in manageable iterations, deploy from day one, and hand over something that can be operated afterwards — not a bag of technical debt.
What's fixed
What we deliver on, every time.
- Demo and rhythm — from build phase 1
- Weekly
- Preview deploy so you test before merge
- Per PR
- Same team from discovery to operations
- End-to-end
- You own code, infra and documentation
- Open by default
Why this way
We've cut it down to what works.
We've tried the opposite: long discovery phases with heavy requirements docs, large teams where information gets lost between roles, and handovers where nobody knows where the buttons are. This is the reaction to that — a way of working that prioritises short loops, direct access, and a handover where the lights are on.
Our method isn't a Methodology with a capital M. It's a set of rhythms and deliverables we keep coming back to, because they make fewer assumptions and give you more real choices along the way. You see progress every week, you can stop whenever, and what we build outlives the day we leave the project.
The three phases
Discovery → Build → Drift.
Each phase has a clear start, a clear end and concrete deliverables. We don't move on without a go from you.
- 01Phase 01 · Discovery
We understand the problem before we solve it.
1–2 weeks together to understand the product, users, constraints and what a realistic first cut looks like. We run workshops, talk to your team, and ask the questions that turn out to matter later. By the end you know whether we're the right match — and what a concrete build engagement costs in time and attention.
- Sketch of architecture and tech choices
- Realistic schedule and milestones
- Risks and open questions
- Recommendation for build-phase scope
- Engagement model (fixed / monthly / hybrid)
- Clear go/no-go decision
- 02Phase 02 · Build
We build in short iterations with deploy from day one.
We set up from Monday of week 1: repo, CI/CD, preview environment, observability. Every pull request gets its own preview link, so you can test features before they merge. Every Friday there's a demo — short, concrete, no theatre. Adjustments and prioritisation happen continuously, not in one big change-request round at the end of a sprint.
- Production stack ready from day 1
- Preview deploy on every PR
- Weekly Friday demos (15–30 min)
- Slack/Teams channel with direct access
- Code review and documentation throughout
- We flag if something needs reprioritising
- 03Phase 03 · Drift
We hand over something that can be operated — or stay on board.
When you're live, you have three paths: we hand over fully (with runbooks, observability, incident procedures and our phone number for a period), we take a fixed operations engagement with uptime targets and response times, or a combination where we keep developing but your team owns operations. It's agreed in Discovery — not as a surprise at the end.
- Auditable runbooks
- Observability and alerting in place
- Incident response procedure
- Documentation your team can onboard from
- Handover workshops for your developers
- Agreed SLA if we keep operations
What we believe
Six decisions we make every time.
These aren't rules. They're choices we consistently make because we've seen what the alternative costs.
Small teams over large
A small team that knows the whole system delivers more than a large team that knows its own slice. We typically put 2–3 people on an engagement, not 6.
End-to-end ownership
The person designing the data flow also sets up the monitoring. That removes handover gaps, and means whoever builds a feature also owns it when it fails at 2am.
Deploy from day one
A staging URL must exist from week one. It forces choices about environments, secrets, CI and observability early — and gives you something to click, not a Figma sketch.
Defensible choices over modern choices
We use Postgres over the newest database vendor, Next.js over the newest meta-framework. Mature and boring beats new and exciting when something needs to stand for five years.
Documentation as we go, not at the end
READMEs, ADRs (architectural decision records) and runbooks are written as we build — not after. That means they actually exist when we leave the project.
Say so when it doesn't fit
If an engagement starts pulling in a direction we can't stand behind, we say so. Better to adjust scope early than to deliver something neither of us is proud of.
How we communicate
Few fixed meetings, lots of direct access.
Weekly demo (15–30 min)
Every Friday we show what landed this week, what got unblocked, and what next week is looking at. Recorded if you can't make it live, so you can watch async.
Shared Slack/Teams channel
You can write directly to whoever built the thing — not an account manager who has to pass it on. We respond within one business day, often faster.
Preview link on every PR
Every pull request gets a preview environment with a unique URL. You can test, comment and approve before we merge to main.
Async demos on short cycles
Between Friday demos we send short Loom/CleanShot recordings when something's ready. Better than a scheduled meeting for something that takes 90 seconds to show.
Monthly retrospective
Once a month we take 30 minutes to look at what's working, what isn't, and whether scope or cadence needs adjusting. We'd rather catch friction early than politely.
Practical questions
What we get asked before we start.
Do we need a requirements document ready before we talk?
No. Discovery is precisely there to find one together. If you have an existing spec, we'll happily read it, but we often expect it to change along the way — that's healthy. What we need from the start is a sense of problem, users and constraints. The rest we figure out together.
What happens if you get sick or disappear mid-project?
We work in small, dedicated teams (typically 2–3), and everything we build is in your repo, your infrastructure, your documentation. If something happens, you can continue with another team without losing control. We also recommend a fixed handover window at end of engagement — that's part of the Drift phase.
How agile are you really? Do you follow Scrum?
We don't follow a particular methodology to the letter. Short iterations, weekly demos, preview deploys, retrospectives — yes. Story points, ceremonies for ceremony's sake and burn-down charts the client has to look at — no. If your team runs Scrum and wants us inside that rhythm, we adjust.
How involved does our team need to be?
At least one business-side decision maker should be available on Slack and at the weekly demos. If you have your own developers who'll continue the work, it's good to have them along from day 1 so they're familiar with the codebase by handover. The rest is optional — we can also run an engagement entirely independently.
What if we want to change scope along the way?
Expected. We work with rolling prioritisation rather than fixed sprints. Larger scope changes (a new feature the size of those already planned) we take a separate conversation about — most smaller adjustments just slip into next week's plan.
Where is your actual team based?
We sit in Region Sjælland and are deliberately remote-first during the build phase itself. Discovery happens in person if you're nearby — and we're happy to come out for larger demos and kickoffs. The development itself runs best remote with our stack.
Ready when you are
Let's talk about what this would look like for you.
30 minutes, no commitment. We'll honestly assess whether we're the right team, and what a realistic first step is.