App Development

It is chosen per project and named in the specification before the quote, rather than being fixed in advance. In practice that means modern JavaScript and TypeScript with React or Next.js on the web, Node services behind them, PHP written to WordPress coding standards for plugin work, Manifest V3 for Chrome extensions, and a cross-platform desktop runtime for Windows and macOS builds. If you already have a stack your team maintains, we build in it — inheriting a codebase your engineers cannot read is a maintenance cost disguised as a delivery.

It is scoped per project and stated in writing before work starts, because the honest answer differs by an order of magnitude between a focused WordPress plugin and a multi-platform SaaS. What stays constant is the shape of the schedule: a discovery and specification phase, then a working end-to-end slice, then milestones you can use on staging as they land. Note that the turnaround figures elsewhere on this site — 3 to 14 days on the fixed-price packages, around 48 hours per retainer request — describe video and motion deliverables, never a software build.

AI tooling is used throughout the pipeline for scaffolding, test generation, refactoring and first-draft documentation, which is a genuine speed advantage and one we state openly rather than hide. It does not merge anything on its own. Architecture, security-sensitive code, authentication, payments and data handling are written or reviewed by the engineer accountable for that area before it ships. The distinction matters commercially: generated code that nobody read is cheap to produce and expensive to maintain, which is the opposite of what you are buying.

Every build includes a defect-fix window agreed in writing during scoping, which covers issues in what we delivered against the approved specification during the first stretch of real usage. Beyond that, ongoing maintenance is optional and quoted separately — typically dependency and security updates, platform changes such as a Chrome manifest revision or a WordPress core release, and small feature work. You are never locked in: because the handover includes the repository, documentation and accounts, another team can take maintenance on without our involvement.

The running application, and everything needed to keep it running without us. That means the Git repository with its full commit history transferred to your organisation, documented environment configuration, a README that gets a new developer running locally, architecture notes, the deployment and release scripts, the automated test suite, and ownership of the hosting and store accounts. Where the product is published on WordPress.org or the Chrome Web Store, the listing is in your name. You own the code outright, with no licence-back and no runtime dependency on us.

Often, yes, but we start with a paid audit rather than a quote. We read the codebase, check dependency health and security posture, look at what tests exist, and come back with a written assessment of what is salvageable, what should be rewritten, and what the realistic cost of each route is. Sometimes that assessment says a rebuild is cheaper than a rescue, and we will tell you so — inheriting a codebase blind is how a takeover turns into an open-ended bill for both sides.