Needs before features
Not every business needs a dashboard, login system, custom backend, or complicated app. If a clean site solves the problem, that is the right answer. If the workflow needs more, it should be scoped clearly.
Local project services
Custom websites and web systems for local businesses
I take on scoped projects to build custom websites and web systems for local businesses, shops, organisations, and communities. Sometimes that means a clean public website. Sometimes it means event pages, forms, dashboards, admin tools, custom storefronts, data-backed workflows, or internal tooling.
The build should match the need, not the other way around. The goal is to preserve what already works about the business, make the public experience clearer, and build the right amount of system behind it.
The website is often the front door. The useful system is what happens behind it: update flows, event pages, forms, dashboards, records, integrations, and tools that reduce repeated manual work.
What matters
Fit first, features second
The work should be useful to the business, clear to the customer, maintainable after launch, and reasonable to hand off.
Keep the identity
The site should feel like the business, not like a generic layout dropped on top of it. The tone, visuals, priorities, and customer experience should still feel recognisable.
Reliability over flash
A site should load, work on phones, make information easy to find, and avoid fragile features that break later. Hosting, domain setup, contact paths, mobile layout, and handoff matter.
Clear ownership
For custom work, the code I write can be documented, handed off, and kept in a repository you can access. Third-party tools, hosting providers, fonts, images, platforms, and services may have their own licences or accounts.
Clear maintenance options
Some businesses want help hosting and maintaining the site over time. Others want a one-time setup and handoff. Both are valid, and the expectation should be clear before launch.
Scoped additions
Extra features are additions, not surprise obligations. New work after launch should be discussed and scoped separately so expectations stay clear.
Complexity when it earns its place
I am comfortable working on deeper custom systems, but complexity should serve the business. If a clean public site solves the problem, that is the right build. If the business needs custom workflows, admin tools, dashboards, data-backed features, storefront logic, search tools, or integrations, those should be scoped and built deliberately.
What I can build
A project can stay focused, or it can include custom workflow pieces when they are actually useful.
Public websites
Clear public pages that make the business easier to understand and contact.
Examples: Homepages, service pages, menus, hours, contact, maps, photos, mobile-first layouts, and clear public information.
Internal tools and workflows
Small systems that help the business update information, collect requests, or track work.
Examples: Admin panels, update workflows, intake forms, quote/request flows, internal trackers, structured records, dashboards, and workflow-specific tools.
Event and community systems
Public pages and simple tools for groups that need people to know what is happening.
Examples: Event calendars, tournament or prerelease pages, signup interest forms, public schedules, Discord/community links, announcement flows, and member or participant information pages.
Storefronts and commerce workflows
Custom storefront and product/event flows when the business needs more than a stock page.
Examples: Custom storefront pages, Next.js/React frontend work when appropriate, preorder interest forms, product/event announcement pages, content-driven product pages, and scoped commerce-backend integrations.
Data and search tools
Lookup, reporting, and retrieval tools for information that should be easier to find or use.
Examples: Searchable resources, document/retrieval tools, lightweight databases, internal lookup tools, reporting views, and workflow-specific utilities.
Hosting, ownership, and maintenance
Launch and handoff work that keeps the site understandable after the first version is done.
Examples: Domain setup, hosting, DNS, basic SEO, social previews, analytics setup, handoff documentation, repository access, optional maintenance, and scoped additions.
E-commerce and storefronts
I am most useful when commerce work needs custom frontend or workflow logic: custom storefront pages, product or event interest flows, preorder forms, content-driven product pages, or integrations around an existing commerce backend.
Commerce boundaries
I am usually not the best fit when the main task is basic Shopify theme setup, drag-and-drop builder configuration, or filling in a premade template. If a hosted builder is genuinely the best answer, I will say that. Larger inventory/POS integrations, payment systems, customer accounts, and complete store operations should be scoped carefully and may belong in later phases or on an existing platform.
Hosting and maintenance options
The launch plan should match how much help the business wants after the first version is online.
One-time setup
I build the site, help launch it, document how it works, and hand it off.
Managed maintenance
I can continue helping with hosting checks, bug fixes, dependency/system updates, small content changes, and minor improvements under a separate maintenance agreement. New features or larger workflow changes are scoped separately.
Phased additions
New features after launch are scoped separately so expectations stay clear.
How a project starts
The early work is mostly about getting the first useful version clear enough to build.
- 01
Understand the business
We talk through what you do, who the site is for, what information people need, and what should stay true to the business.
- 02
Define the first useful version
The first version should solve the real problem. That might be a better homepage, an event page customers can trust, a way to collect interest, or a small workflow that replaces repeated manual messages.
- 03
Build and review
I build the agreed version and keep the review focused on whether it matches the business, works clearly, and solves the intended problem.
- 04
Launch or hand off
I can help with hosting, domain setup, deployment, and maintenance, or I can set it up once and hand over the code and documentation.
- 05
Add features only when they earn their place
The project can grow in phases. More complex features should be added because they are useful, not because they sound impressive.
Example starting points
A few ways this kind of work can start, depending on the business, community, or workflow.
For a card shop or game store
event calendar, prerelease pages, Discord links, product announcements, preorder interest forms, new-player info, and custom storefront or event workflows when useful.
For a restaurant, cafe, or local shop
menu/service pages, hours, location, specials, photo sections, inquiry forms, update workflows, and customer-facing announcements.
For a service business
service pages, quote request forms, intake workflows, project galleries, follow-up flows, and internal tracking tools.
For a club, school group, or local organisation
event pages, resource libraries, document search, member info, announcement workflows, and simple admin tools.
Scope boundaries
The best first version is clearly scoped: a public site, event/workflow layer, custom frontend, small web app, data-backed tool, or internal workflow system.
Larger systems like complete commerce operations, payment processing, inventory/POS integrations, regulated workflows, or customer accounts can be discussed, but they should be scoped as separate phases rather than assumed in the first build.
Project conversation
Have a site or workflow in mind?
Send a short message with what you do, who the site or system is for, and what you are hoping it helps with.
You might be trying to make information easier to find, reach more people, improve your public presence, support events, collect interest, give customers more options, or make a repeated workflow easier.
You do not need to know the whole scope before reaching out. A first conversation can sort out what should stay simple, what might need custom work, and what can wait.
Helpful to include:
- what you do
- who the site or system is for
- what you want it to help with
- whether you already have a site or domain
- any rough timeline you have in mind