Plain HTML, CSS and JavaScript
When the page is the product — marketing sites, documentation, content libraries. Nothing to hydrate, nothing to break, and a crawler sees the finished page on first request.
Web development
Websites and web apps that earn their keep
Marketing sites that rank and convert, dashboards your team lives in, and backends that don't fall over — built fast, built properly.
Full-stack web development, from marketing site to admin dashboard
Most of what gets called "a website" is really two different products wearing the same domain. One is the public face — it has to load fast on a mid-range phone, say what you do in the first screen, and rank for the things people actually search. The other is the software your team opens every morning: a custom web application with roles, records, and workflows, where speed matters less than not losing anyone's data.
We build both, and we build them differently. A marketing site gets static HTML, aggressive caching, and a structured-data layer so search engines can read it without running JavaScript — the approach behind the searchable code library we built for a developer YouTube channel, where near-instant loads and zero running cost were the whole point. An admin dashboard gets real state management, server-side authorization, and an audit trail.
The overlap is the backend. Whether you need a contact form that reliably reaches a human or a multi-tenant API, the same questions decide the build: who is allowed to read this, what happens when it fails, and who fixes it in eighteen months.
What a web engagement covers
- SEO-ready marketing websites with semantic HTML, per-page metadata, structured data, and Core Web Vitals treated as a build requirement rather than a later fix
- Custom web applications and admin dashboard development shaped around your actual workflows, not a template's idea of them
- Firebase and Node.js backends with REST or GraphQL APIs, authentication, and role-based access rules
- E-commerce storefronts with payments, catalogs, and a checkout built to be measured and improved
- Performance audits and rescues for slow or fragile existing sites
- Hosting, custom domains, analytics, and deployment pipelines — configured, documented, and handed over
Typical stack
Related work
Two production builds that show the range — a lead-generating business site and a content platform built for search.
Project fit
Is a custom web build the right call for you?
You're in the right place if you…
- Need a credible site that converts visitors instead of just existing
- Are replacing a slow or fragile legacy build you've stopped trusting
- Want an internal dashboard or customer portal that fits how you already work
- Sell online and care about what happens between the product page and the receipt
- Have a backend that works but a front end that embarrasses you, or the reverse
We're probably the wrong call if you…
- Want a template dropped in and handed back the same week — a page builder will cost you less and serve you fine
- Need someone to take over a large codebase with no documentation and no original team available for questions
- Are looking for ongoing SEO content marketing rather than the technical foundation underneath it
- Need on-site staff or work that cannot be done by a remote team
Architecture
How we choose a stack, and why it's usually boring
Novelty is a cost you pay every time someone new opens the repository. We spend it deliberately.
React when state earns it
Dashboards with filters, live data, and half a dozen interacting panels are where a component model pays for itself. Below that threshold it is overhead your users download.
Firebase for speed to market
Auth, Firestore, hosting and rules out of the box. You trade some control for weeks of calendar time — worth it when the product still has questions to answer.
Node.js when the logic is yours
Once business rules stop fitting in security rules — billing, integrations, scheduled jobs, anything with a third party on the other end — a real server is the honest answer.
Firestore, and where it stops
Excellent for document-shaped data and real-time listeners. We will tell you when your reporting needs relational queries instead of a NoSQL workaround.
Stripe over bespoke billing
Card data never touches your servers, and the compliance surface stays with the people who specialise in it.
Engagement
What the weeks actually look like
No status theatre. You see working software on a URL early, and it stays on that URL as it grows.
Scope
We pin down pages, roles, and integrations, then write the estimate against that — not against a hopeful average.
Structure
Information architecture, URL structure, and the data model. Getting URLs right on day one avoids redirect debt later.
Build
Weekly increments on a staging URL you can open any time. You review real pages, not screenshots.
Harden
Performance, accessibility, security rules, error states, and the analytics you will actually read.
Launch
DNS, SSL, caching, sitemap and search console — then a documented handover of every credential.
The rhythm is deliberately dull: a weekly demo, an honest changelog, and early bad news when something turns out harder than scoped. It is the same way we run MVP product development — and the reason clients usually know about a slipped estimate before we have finished diagnosing it. More on how we work is on our about page.
Performance, security, and the code you inherit
Performance is a budget, not a score
Core Web Vitals get treated as a constraint during the build rather than an audit afterwards. In practice that means images sized and lazily loaded, fonts subset and preloaded, JavaScript shipped only where it changes behaviour, and static assets served from a CDN with long cache lifetimes. A page that starts fast tends to stay fast; a page rescued at the end rarely does.
Security that assumes the client is hostile
Anything a browser sends can be forged, so authorization lives on the server or in Firestore security rules — never in the interface that renders the button. Secrets stay out of the client bundle and out of the repository. Third-party payment and auth providers do the parts that carry regulatory weight. Dependencies are kept few, because every one of them is a door.
Maintainability means the next developer
We write for whoever opens the project after us, on the assumption it will not be us. That means predictable file structure, comments that explain why rather than restating the code, and no clever abstraction that saves ten lines and costs an afternoon of reading. If a build step exists, it is one command and it is written down.
What you get at handover
- The full source repository, under your account, with its commit history intact
- A README covering local setup, the build command, and how to deploy
- Every credential and account — hosting, domain, analytics, payment provider — transferred to you
- The data model and security rules documented in plain language
- Environment and configuration notes, so a rebuild does not depend on our memory
Ownership
You own one hundred per cent of the code from the first commit. There is no proprietary framework to license, no hosting you are locked into, and no clause that makes leaving expensive. If you later move the work in-house or to another team, everything they need is already in the repository.
FAQ
Web development questions
How long does a custom web application take?
A focused marketing site typically ships in 2–4 weeks. Web applications and admin dashboards usually run 6–12 weeks depending on how many roles, integrations, and workflows are involved. You get a timeline before anything is signed, and you hear about slippage when we spot it, not at the deadline.
Will the site be SEO friendly?
Yes — semantic HTML, per-page titles and meta descriptions, Open Graph tags, structured data, a generated sitemap, and fast load times are part of every build rather than an upsell. What we do not do is ongoing content marketing; we build the technical foundation that makes content worth publishing.
Do you build with React, or plain HTML and JavaScript?
Whichever the page justifies. Content and marketing pages are usually static HTML so they render instantly and crawl cleanly. Dashboards and anything with heavy interactive state get React. We do not add a framework to a brochure site to keep our tooling consistent.
Firebase or a Node.js backend — how do you decide?
Firebase when the product still has questions to answer and speed to market matters most: authentication, Firestore, hosting and security rules arrive working. Node.js when your business logic outgrows security rules — billing, scheduled jobs, third-party integrations, or anything that needs a trusted server. Plenty of builds use both.
Can you build an admin dashboard on top of our existing system?
Usually yes, provided there is an API or direct database access we can read and a way to authenticate. We start by mapping what already exists, then build the interface against it rather than migrating your data somewhere new.
Do you handle hosting, domains, and deployment?
Yes. We typically deploy to Firebase Hosting with your custom domain, SSL, and caching configured, plus a deployment process documented so anyone on your side can ship. The accounts are yours, so you are never dependent on us to stay online.
Can you improve our existing site instead of rebuilding it?
Often, yes. We start with an audit of performance, structure, and code quality, then either optimise in place or migrate your content into a cleaner build — whichever gives the better result for the budget. Rebuilding is a recommendation we have to justify, not a default.
Who owns the code and the accounts?
You do, entirely, from the first commit. The repository lives under your account, every third-party service is registered in your name, and the handover includes documentation written for a developer who has never spoken to us.
What happens after launch?
Your choice. Some clients continue on a monthly retainer for new features, monitoring, and dependency updates. Others take the documented handover and run it with their own team. Both are normal, and neither costs you access to anything.
Next step
Ready to build something that grows?
Tell us about your product. You'll get a straight answer on approach, timeline, and cost — usually within 24 hours.