Let's talk about your project

Every project starts with a call rather than a form. We ask about the problem you are solving before the feature list, because the feature list usually changes once the underlying problem is clear. After that we send a written proposal: scope, timeline, price or hourly estimate, and what we need from your side to hit that timeline (usually one clear decision-maker and reasonably fast feedback on demos).

Once you sign off, a short kickoff call confirms scope and introduces the engineers building your project. Work happens in short milestones, typically one to three weeks depending on project size, and each one ends in something you can click through on a staging URL rather than a status report. We check in on a fixed cadence, weekly for most projects and more often near launch, and you’re never stuck waiting for a scheduled call to get an update.

Launch isn’t the end of the relationship. We hand over the code, credentials, and documentation, and talk through what support looks like afterward, which is covered below.

Both, depending on how well-defined the work is. If you can tell us what you want built — a WooCommerce store migration, a set of Shopify Liquid templates, a mobile app with a fixed feature list — we’ll quote it fixed-price against a written scope document. You know the number before we start, and so do we.

If the work is genuinely open-ended, we bill hourly or on a monthly retainer instead, usually with a not-to-exceed cap so there’s still a ceiling. That covers things like an MVP where the feature set is still being figured out, or an ongoing n8n automation build where new workflows get added as you discover new bottlenecks. Hours are tracked and reported, so you can see where the time went rather than taking our word for it.

What we won’t do is quote fixed-price against a vague brief. That’s how projects end up arguing about what counts as “in scope.” If the brief isn’t tight enough to price properly, we’ll ask more questions or suggest a short paid discovery phase first.

You do. Once final payment clears, you own the code, the designs, and everything else we built for you, full stop. That’s written into the contract, not left as a verbal understanding.

You don’t have to wait until the end to see any of it, either. We typically build in a repository under your own GitHub or GitLab organization from day one, so you have access throughout the project. If we start in our own repo purely for setup convenience, we transfer it at completion. Either way, you leave with the actual commit history, not a zip file handed over at the last meeting.

The one exception is anything licensed from a third party on your behalf, such as a premium WordPress plugin, a paid Shopify app, or a font license. That stays governed by the vendor’s own terms, the same as if you’d bought it directly yourself.

You can. Nobody is locked into a project they’re unhappy with, and we would rather you leave cleanly than stay resentful.

In practice, you pay for work completed and accepted up to that point, which is one reason we bill in milestones rather than a single lump sum at the end. We hand over everything built so far — code, assets, credentials, documentation — and we’re available for a short handover call if you’re moving to another team. We don’t hold work hostage over a disagreement, and we don’t charge a termination fee.

If something is wrong, we’d genuinely rather hear about it and try to fix it than have you quietly plan an exit. Most “we want to stop” conversations we’ve had turned out to be scope or communication problems that were fixable within a week or two.

Yes, usually before we’ve seen anything beyond a one-line description of the idea. We’ll sign yours if you have one, or send ours if you don’t. We’re not precious about the template.

Beyond the NDA itself: project details stay with the people actually working on your build, client repos and environments use separate credentials rather than shared logins, and we don’t publish case studies, portfolio entries, or marketing material naming your company or showing your product without asking first. If we want to reference the project publicly at all, even anonymized, we’ll check with you before we do.

Regularly, yes — and we’d rather find out what we’re actually dealing with than quote blind. New codebases start with a short paid audit: a few days going through the code, the hosting setup, and whatever documentation exists (often not much), so we can tell you honestly what state it’s in before committing to a timeline or a price. Sometimes that audit changes the recommendation entirely — a plugin conflict that looked like it needed a full rebuild turns out to be a one-line fix, or a database that looked slow just needs better indexes instead of a replatform.

If the audit turns up something genuinely unsalvageable, we’ll say so, and we’ll say why — not just because the code is unfamiliar or written differently than we would have written it. Inheriting someone else’s decisions is a normal part of this work, not a reason to recommend starting over.