Straight answers to the questions we actually get asked.

A custom marketing site takes 4–8 weeks. A mobile app or SaaS MVP takes 10–16 weeks. A full ERP implementation is phased, with the first working module usually live in 8–12 weeks. Every timeline includes 1–2 weeks of discovery and is confirmed in writing before development starts.

Discovery is where we audit your existing systems, interview the people who use them, define success metrics and model the technical load. It produces a written architecture brief with fixed scope, timeline and cost. It’s paid because it’s real engineering work — and it’s the only phase you can buy on its own.

We can compress discovery, run parallel workstreams and phase the launch so the critical path ships first. What we won’t do is skip architecture or QA — those are the two shortcuts that reliably cost more time later than they save now. Tell us the deadline at the start and we’ll tell you honestly whether it’s achievable.

If the delay is ours, we absorb it and the fixed cost doesn’t change. If it comes from a scope change or a hold-up on your side, we tell you the timeline impact when it happens rather than at the end. You get a written weekly update throughout, so a slipping timeline is visible in week two, not week ten.

Buy off-the-shelf when your process is standard and the platform’s assumptions match how you already work. Build custom when your business logic is specific, when you’re paying for workarounds, or when multiple systems need to share data cleanly. The deciding test is simple: are you changing your process to fit the software?

For standard requirements they’re a reasonable choice and we’ll tell you so. They become expensive when your logic gets specific — plugin conflicts after updates, licence fees stacking, performance ceilings, and workarounds nobody can maintain. The failure pattern is consistent: the platform works until one requirement it can’t support turns into three months of hacks.

Extend, in most cases. We start with a technical audit and tell you what’s worth keeping. A full rebuild is a recommendation we make rarely and always justify in writing — usually only when the data model itself can’t support where the business is going.

You do, entirely, from day one. Code is committed to your repository throughout the build, not handed over at the end. You also receive infrastructure and admin access in your own accounts, full documentation, and a handover session with the engineers who built the system.

The handover is a folder, not a negotiation. Standard technologies, documented architecture, clean commit history, credentials already in your name. We’d rather keep clients because leaving is easy and staying is better than because switching is painful.

Security is reviewed as a build phase, not an afterthought: dependency auditing, access control verification, input validation, encryption in transit and at rest, and a review before anything reaches production. For regulated sectors, the specific requirements are defined during discovery and designed into the architecture rather than bolted on.

Only the engineers assigned to your project. We work in your cloud accounts wherever possible, so you retain control and can revoke access at any time. Where we need production data for migration or testing, we use anonymised copies unless there’s a specific reason not to.

A shared Slack or Teams channel with your project team in it, a written update every Friday, and a live sprint review every two weeks where you use the current build. You also get repository, staging and project board access from day one, so you never need to ask for a status update.

The senior engineer who scopes your project leads the build, supported by the specialists it needs. No junior work shipped unsupervised, no undisclosed subcontracting, no rotating developers relearning your codebase. You talk directly to the people writing the code.

Regularly. We can own the architecture while your team builds features, take one workstream while yours takes another, or come in purely for a specific capability like performance or AI. Responsibilities are agreed during discovery so nothing sits in a gap between two teams.

One empowered decision-maker, access to the people who actually use the current systems, feedback within about five working days, and existing assets — brand files, content, credentials for systems we’re integrating with. If any of those are difficult, say so during discovery and we’ll plan around it.

Every project includes a 30-day post-launch window where defects are fixed at no cost. After that, you either take full ownership — you have the code, docs and access to do so — or move onto a growth retainer covering performance, SEO, conversion and new features. Both are normal.

No. Nothing about the delivery depends on an ongoing contract. Clients who stay on a retainer do it because continuing optimisation is worth more than the fee, not because they’re stuck. Clients who take it in-house get everything they need to do that cleanly.

Retainers are monthly and scoped to the work you actually want — anything from a small support allocation to a dedicated team on a continuing roadmap. It’s quoted after we know the system’s real support profile, which is usually clearer a month after launch than before it.

Yes. Each of the six services stands alone and most engagements start with one. The advantage of the full stack is that integration work between systems disappears — but that’s a reason to expand later, not a condition of starting.

Yes. Interface design is part of Phase 02 — wireframes, high-fidelity screens and a component system, with two full revision rounds. If you have an existing brand or design system, we build to it rather than replacing it.

Often, yes. It starts with a technical audit so you know what you’re carrying before anyone commits to a plan. Sometimes the honest finding is that the existing code costs more to untangle than to replace, and we’ll show you the reasoning either way.

We build them, and we scope them against a measurable process cost. That means autonomous agents for repetitive operational work, NLP pipelines trained on your data, and predictive models for demand, churn or capacity. If a proposed AI feature doesn’t have a number attached to what it saves, we’ll say it isn’t worth building yet.