This page is for IT managers evaluating a handover, web designers considering a referral arrangement, or anyone doing technical due diligence on behalf of a client. No marketing language. Just the stack, the architecture decisions, and an honest account of what I do and don't do.
Every site I build uses the same deliberate, composable stack. Nothing here is chosen for novelty; each component has a specific reason for being in or out.
Astro pre-renders pages at build time into pure HTML and CSS, shipping zero JavaScript to the browser by default. No client-side runtime, no hydration overhead, no front-end dependency chain to maintain.
Tailwind CSS handles all styling, producing a minimal, purged CSS bundle at build time. Both are open source, well-documented, and widely supported. A competent front-end developer can work with either without retraining.
All sites are deployed to Cloudflare Pages and served from Cloudflare's global CDN. Server-side logic (form processing, data queries, API routes) runs in isolated Pages Functions (Workers at the edge), spinning up only on demand with no persistent process to probe. The public-facing layer remains static; compute only activates at specific, validated endpoints.
Every client's site runs under their own Cloudflare account. I'm added as an administrator during the engagement and removed if the engagement ends. The site keeps running without interruption either way.
D1 is Cloudflare's managed SQLite-at-the-edge database, used for structured transactional data: form submissions, event registrations, reference number management, and similar. All queries run through server-side Workers with validation and spam verification before reaching the database layer. D1 is never exposed directly to the public internet.
One database per client site. I document the schema and hand it over with the project. Data is exportable as SQL at any time.
R2 handles binary assets: uploaded files, images, payment screenshots. S3-compatible, no egress fees. Client-uploaded files are written directly to R2 via signed upload URLs; they never pass through the Worker as a buffer.
Transactional email for confirmations, notifications, and internal alerts. Each client maintains their own Resend account with me as administrator. Sending domain is verified against the client's own domain. No shared sending infrastructure.
Cloudflare's passive browser challenge: no image puzzles, no friction for genuine users. Server-side token verification happens in the Worker before any data is written to the database. A submission that fails verification is rejected before it touches any storage layer.
Privacy-first analytics with no cookies and no personal data collection. No consent banner required, which is not just a UX preference but a practical PDPA position. Under PDPA, consent is required for the collection of personal data. Plausible collects none, which eliminates the requirement entirely.
Google Analytics 4 is not used by default. Where a client has an existing GA4 dependency for ads or conversion tracking, I treat this as a scoped exception with the privacy implications documented explicitly.
My choice to pre-render everything at build time rather than compute pages at request time has three concrete consequences:
A pre-rendered HTML file served from an edge node close to the user is fast before any optimisation work. A WordPress page querying a database on shared hosting is slow before any optimisation work. The difference between a well-built static site and a typical SME WordPress installation is not marginal; it is an order of magnitude.
There is no database connection exposed at runtime. No interpreter executing user-influenced input at the public layer. No plugin ecosystem with a maintenance lag. The public-facing layer is static files with security headers. Server-side logic runs in isolated Worker functions with no persistent state between requests.
A pre-rendered Astro site is a folder of HTML, CSS, and JavaScript files. It deploys to Cloudflare Pages, Netlify, Vercel, an S3 bucket, or a traditional VPS without modification. No proprietary runtime, no database export, no theme licence to negotiate. The client owns a git repository. That repository is the product.
Ownership has a specific technical implementation, not just a policy statement.
The practical test: if I walked away tomorrow, every client site would continue running, every email would continue sending, and every piece of data would remain accessible to the client. Nothing would break. That is the bar I build to.
Registered in the client's name, on a registrar account the client controls. DNS is managed via the client's own Cloudflare account.
The Cloudflare Pages project lives in the client's Cloudflare account. I'm an administrator, not the account owner. Removing my access does not affect the site.
The site lives in a git repository owned by the client (GitHub, GitLab, or Bitbucket, client's choice). At any point, the client can hand the repository to another developer. Standard TypeScript, Astro components, and SQL throughout: nothing proprietary, nothing obfuscated.
The D1 database and Resend account both belong to the client. I document the schema. Data is exportable as SQL. The sending domain is on the client's own domain. I hold administrator access, not ownership.
My forms and digital tools work goes significantly beyond styled contact forms.
A representative example is a charity gala event registration system featuring visual contestant selectors, real-time price calculation, dynamically generated PayNow QR codes, pre-assigned reference numbers, and payment screenshot upload, built for a Singapore-based organisation after two prior attempts using off-the-shelf tools failed to meet the requirements.
I document and hand over the specification and testing detail for every engagement. The client receives not just working software but a clear record of how it was designed to behave and what to expect when things go wrong.
I work best with a specific type of engagement. The following are outside scope, and I'd rather state this clearly than have it surface mid-project.
Sites requiring real-time multi-user state, complex session management, or SaaS-grade application architecture are not the right fit for how I work.
High-SKU catalogues with inventory sync, order management, and fulfilment integrations belong on a dedicated e-commerce platform. Simple product catalogues with manual inventory are achievable; automated stock management at scale is not.
My stack does not include a drag-and-drop layout editor. Content updates are handled through the retainer model. Where full self-service editing is a hard requirement, a headless CMS layer can be added as a scoped addition.
CRM pipelines, marketing automation workflows, Zapier-style connections to external platforms: I don't build or maintain these. The principle is that client data stays within infrastructure they control.
I work solo with a deliberately limited client roster. I'm not the right fit for a brief that requires simultaneous workstreams, a dedicated project manager, or guaranteed SLA response times measured in hours.
Several of my clients come via designers and freelancers who handle visual and brand work but prefer not to carry hosting infrastructure and ongoing technical stewardship.
The arrangement that works: the designer owns the visual relationship and brand direction; I own the technical build, infrastructure, and maintenance retainer. The client has one point of contact for design and one for technical, both independent, with no agency overhead in the middle.
What I don't take on in a referral arrangement: visual design, brand identity, illustration, or photography. That stays with you.
If you have a client who needs a technically rigorous build and ongoing stewardship, a conversation is straightforward to arrange.
If you're evaluating me on behalf of a client, doing due diligence before a referral, or have a specific brief to discuss, a direct conversation is the most efficient route.
For a fuller picture of how I work, including how projects are scoped, documented, and handed over, that is covered in a separate briefing available on request.