Frequently asked questions

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.

Both, and the two engagements look fairly different. Startups usually come to us pre-product or pre-seed and need something built fast and lean enough to test with real users. If an idea doesn’t actually need a custom build yet — a well-configured no-code stack would get the same validation for less money — we’ll say so rather than sell a bigger project than the stage calls for.

Larger, established companies usually arrive with more constraints: existing systems to integrate with, a security review to pass, several stakeholders who need sign-off, and less appetite for figuring things out as we go. Those projects get more upfront documentation and a slower, more formal process, because that’s what actually serves them.

What doesn’t change between the two is who writes the code. Senior engineers either way, not a training ground for junior developers on your budget.

No. We work for cash, billed against milestones or on a retainer, the same as any other vendor. That’s not a judgment on equity deals in general. It’s that we’re a services business with engineers and marketers to pay every month, not an investment fund, and taking equity in a pre-revenue company in exchange for real engineering hours is a bet we’re not set up to make responsibly.

If budget is the actual constraint, say so. We’re generally far more flexible on scope — building less, shipping a real MVP instead of the full vision — than we are on how we get paid for the work we do take on.

Yes, and we’d recommend it for anything more complex than a brochure site. There’s a warranty window right after launch, where anything that’s genuinely a defect in what we built gets fixed at no extra cost, followed by an optional monthly retainer for everything after that: security patches, WordPress and plugin updates, dependency upgrades, monitoring, small feature requests, and an actual person to call when something breaks at an inconvenient time.

You’re never required to take a retainer. The code is yours, and you’re free to hand maintenance to an in-house team or a different agency entirely. But “just fix it if something breaks” without a retainer in place means queuing behind clients who do have one, and ad hoc emergency work costs more per hour than the same work done under a standing agreement. Most clients who skip the retainer at launch ask for one within a few months, usually right after the first thing breaks late on a Friday.

Always. Every project runs on a written agreement covering scope, price, timeline, payment schedule, IP ownership and confidentiality, signed before any work begins or, at minimum, before a paid discovery phase starts.

We use standard commercial contract terms your legal team can review, and we are equally happy to work from your own paper if you already have an MSA in place.

There is no published minimum. Scoping, testing and handover take roughly the same effort whether a build is small or large, so very small projects carry a higher cost per feature, but that does not rule them out.

Focused work is often worth doing properly at a small scale: a targeted WordPress plugin fix, a specific change to a Shopify Liquid template, or a compact AI or automation proof-of-concept that proves a case before a larger investment. Tell us what you need and we will quote it or tell you plainly if another route serves you better.

For a genuinely small, self-contained job — a single landing page, a one-off script, a quick WordPress fix with no ongoing complexity — a good freelancer will often be faster and cheaper, and we will say so.

Where an engineering company earns its rate is on anything with more than one moving part or any real time horizon. A freelancer is one person’s calendar. If they get sick, take a better offer, or just go quiet, which happens more often than anyone likes to admit, your project stops with no backup plan. We keep more than one engineer familiar with your codebase, so leave or a resignation does not become your emergency. You also get a second set of eyes on architecture decisions before they’re expensive to reverse, someone thinking about security and testing without being explicitly asked to, and a business that’s still reachable in eighteen months when you need something changed.

None of that matters much for a five-hour job. It matters a great deal for anything you’re planning to depend on.

We break the project into milestones during scoping, each tied to a specific, demonstrable piece of work rather than an arbitrary date on a calendar: discovery and design sign-off, core build complete on staging, integrations and testing complete, launch, that kind of structure.

Each milestone carries a payment, invoiced once it’s delivered and reviewed, not before. A typical structure is a deposit to begin, often in the 20 to 30 percent range, with the remainder spread across the following milestones and a final payment due at launch. For fixed-price work this also caps your risk: you’re never paying for more than what’s actually been delivered and accepted, and we’re never carrying the full cost of a large build with nothing paid until the very end.

For hourly or retainer work it’s simpler: invoiced monthly against logged hours, with time tracking you can actually see rather than a single total at the end of the month.

It usually does, a little, and that’s normal rather than a sign the planning was bad. Small adjustments — swapping one integration for a similar one, tweaking a workflow once you see it running — we typically absorb without a formal change order if the effort roughly nets out. Anything that meaningfully adds work, like a new feature, a new integration, or an “actually we also need it to do this” request, gets scoped and quoted as a change order before we build it, so you’re deciding with real numbers instead of finding a surprise on the final invoice.

What we try hard to avoid is silent scope creep in either direction: us quietly absorbing extra work and resenting it later, or you assuming something was included that never actually was. A short conversation and a written estimate before the work starts usually heads off both.

Yes, as part of how our engineers work day to day, the same way most serious dev shops do at this point. Tools like GitHub Copilot and Claude speed up boilerplate, first-draft test coverage, and routine refactors. What we don’t do is pipe your spec into a model and ship back whatever comes out. Every line that reaches your repository has a senior engineer who read it, understood it, and is willing to put their name on it in a pull request.

When AI is the actual product we’re building — a support chatbot, a document classification pipeline, a RAG system over your knowledge base — that’s a deliberate, scoped engineering decision like any other, handled under AI Services rather than bolted on because it’s trendy. If you’d rather we not use AI-assisted coding tools on your project at all, that’s a fine conversation to have. It usually costs more in hours, but it’s your call.