Questions
and answers.

A typical engagement runs from a few weeks to a few months. Fixed scope and fixed quote, agreed during scoping. Timeline is committed against that scope - if your priorities shift, we reprice and replan transparently. Review rhythm and ways of working match how your team already operates.

Fixed quote per scope. What we scope is what we quote, and what we quote is what you're invoiced. New work or scope changes are scoped and quoted separately, before we build.

A focused team of experienced operators, a single point of contact, and a planning rhythm tailored to the project. Regular demos, shared tooling in whatever your company already uses, and no account managers between you and the engineers doing the work. Most first engagements start small - an audit or a fixed-scope pilot - and scale on results.

Both. Growth-stage companies rescuing or scaling existing systems, and seed-to-Series A founders building from zero. The work looks different; the bar doesn't.

Absolutely. We embed with your engineers, follow your processes, and leave your codebase better than we found it. Full documentation and team training included.

Launch is mile one. Most clients keep us on - some for years - because they come to us before the next move, not just to execute it. We challenge assumptions, propose the smart play, and own the technical side of decisions your business rides on. One team. One quote. One long-term partnership.

Yes - most of our clients don't. We sit on your side of the table: pick the stack, make the architecture calls, evaluate vendors, and talk to your board when it matters. On long engagements, this often evolves into a fractional CTO role. You stay in control of the business; we own the technical outcome.

The source code with its full history; admin access to hosting, the domain, the database and every external service; build and deployment instructions; recent backups; and a list of integrations and known issues. Then check what matters most: that the new team can actually build, run and deploy the product from what you handed over. The six evidence packs a receiving team needs are in Can another team own your AI-built product?

Yes. We take over codebases other teams built, and we always start with an audit: the state of the code, what we can access, what needs fixing first. Missing documentation doesn't stop us; we write it during the audit. Missing access does: we can't take over a live product without its source code and production environment. In that case we first help you get them back - the domain, hosting, code repositories and app-store accounts belong to you. If the source code can't be recovered, we quote a rebuild instead. See Long-term Support & Maintenance.

In stages, while the product keeps running: an audit, the biggest risks fixed first, then step-by-step modernisation - the approach of our rescue missions. Before we take over production, we check that we can build and release the product ourselves, that backups exist and can actually be restored, and that every password and access key has been handed over and changed, with the previous team's access removed. We also make sure monitoring alerts reach us, and we agree with you how to roll back and, if needed, a maintenance window.

Everything that's yours stays yours. If the engagement ends, we hand over all work in progress and the source code produced to date (Terms, section 8), and your accounts and infrastructure are already in your name. The rest of the exit package - repository and workflow exports, infrastructure settings, deployment and recovery instructions, the access list, known issues, handover sessions or training for the next team - is specific to each project and agreed under a separate contract, budget and plan.

Yes - the same way a surgeon uses power tools. AI drafts boilerplate, scaffolds tests, and speeds reviews. An experienced engineer owns every line that ships: reads it, tests it, signs their name to it. We don't paste LLM output into production and hope. Every repo we hand over is typed, tested, and traceable to a human decision.

Yes - and it's one of the fastest-growing parts of our work. We take codebases that "worked in the demo" and make them survive production: secrets cleaned, dependencies pinned, dead logic removed, tests added, infrastructure hardened. For M&A and investor diligence, we also do standalone audits - architecture review, AI-code provenance, security posture, and a clear risk score you can defend to your partners.

Yes - hands-on corporate AI training built on your real workflows, not generic slides: ChatGPT, Claude, Copilot, Gemini. From a half-day AI-literacy kickoff to a multi-week program, on-site or remote, run by the engineers who put LLM systems into production. Fixed quote per scope.

They're four different events. A mention: your brand appears in an AI answer. A visit: someone lands on your site. An enquiry: a message or form submission reaches you. A booked meeting: someone completes a calendar booking. Whether an enquiry is qualified - the right client with the right need - takes a separate human review. Our AI Visibility Audit measures the first: how often ChatGPT, Perplexity, Google AI Overview and Gemini cite you.

We pick the tool that fits the problem, not the one trending on X. Web & applications: Vue, React, Next.js, Node, NestJS, Drupal, WordPress. Mobile: React Native. Commerce: Magento, custom storefronts, unified-commerce platforms. AI & automation: LLM integrations, agent systems, workflow automation. Web3: blockchain, smart contracts, crypto infrastructure. Growth layer: SEO and content systems.

Usually, yes. We connect to the CRM, ERP and other tools you already run rather than replacing them. First we check what each tool allows: its API, access rights, data structure and limits on data exchange. Then we propose the integration, or tell you plainly which part can't be connected reliably and what the options are.

On every integration, four things are settled before anything is connected: what data moves and which system holds the master copy; how records are matched between the two; what happens when data is sent twice, a call fails or an API is down; and who gets alerted and who is responsible for fixing it. Error handling, retries, alerting and documentation are built into every workflow we ship, as in our n8n AI automation work.

Working worldwide with clients in every major market. Upon full payment, all code, designs and deliverables created for your project are assigned to you - you own them outright, no clawbacks. We only mention the work in our portfolio as an anonymised description, and not at all if you opt out in writing. NDAs signed before the scoping call. GDPR-compliant by default, data-residency options on request. Enterprise procurement teams: we've been through it - send the questionnaire.

You do. n8n, cloud infrastructure and external services are set up on your own accounts, and you have admin access from day one. The code, designs and deliverables created for your project are assigned to you upon full payment; pre-existing tools, libraries and frameworks we bring stay ours (Terms, section 4).

A standard retainer covers uptime monitoring, bug fixes, security patches, dependency updates and a monthly report. Coverage hours, severity levels and response times are set per contract, based on what your product needs. See Long-term Support & Maintenance.

A bug is the product not doing what was agreed. An update keeps it compatible, secure and maintainable: dependency upgrades, security patches, platform changes. A new feature extends what was agreed. Bugs found in the 60 days after delivery are fixed at no extra cost under the warranty; after that, bugs and updates are covered by the support scope. Anything outside that scope is quoted separately, through a written change request, before we build. Third-party API changes are the usual grey area, so the support scope says how they are handled; on our n8n care plans, for example, the fix is included.

The statement of work fixes the scope, deliverables, timeline, price and acceptance criteria before work starts. At delivery you get the test scenarios, a test report listing any open issues by severity, release notes, deployment and rollback instructions, and the documentation. Acceptance is a signed sign-off; minor issues can be listed as reservations and fixed under the 60-day warranty.

Proof is provided on request, matched to your project. Our case studies show the range of work we've delivered.