Ardent Health
A patient portal replacing a spreadsheet and a shared inbox. Roles, audit trail and an appointment flow that had to work on a ten-year-old phone.
Custom web application · Nuxt + Postgres · 2025Service · Direct
Web development, from a marketing site to a working application
Some projects are a website. Some are software with a website attached. We build both, in the same stack, and we tell you which one you have before you commit to a budget.
01Scope
What we build
Marketing and content sites
The site that has to load fast, rank, and be editable by someone who is not technical. Built from a design rather than a purchased theme, with the content model designed around how you actually publish.
Custom web applications
Portals, dashboards, booking and quoting systems, member areas, internal tools — the things that start as a spreadsheet and stop working at about thirty users. Built with real accounts, permissions, an audit trail and somewhere for the data to go.
If it is specifically about customer records, quotes and internal process, see CRM and intranets.
Headless and decoupled builds
A modern front end with a CMS behind it that your team already knows how to use. Common shape: a Nuxt front end reading from WordPress or a commerce backend, so editors keep the interface they are used to and visitors get a site that loads immediately.
Integrations and APIs
Connecting the site to the systems that already run the business — payment providers, CRMs, stock and accounting systems, email platforms, internal databases. Including the ones with documentation written in 2013.
Rescue and performance work
Core Web Vitals, a site that has become slow, a build nobody can deploy any more, or a codebase whose author has gone. We take these on. It usually starts with a written assessment of what is actually wrong, which is a smaller commitment than a rebuild and often avoids one.
02Method
How we build
The stack we use, and why
Nuxt and Vue for front ends, Tailwind for the design system, WordPress and WooCommerce where content editing or commerce is the centre of the project, PHP and MySQL behind them.
We are deliberately narrow. A small stack used well produces sites that can be handed to another developer, which is the property that matters most three years after launch.
If your project needs something outside that, we will say so on the first call rather than learn it at your expense.
Performance, accessibility and search are build tasks
Page speed, keyboard access, heading structure, metadata, canonical tags and redirects are part of the build and are checked before launch. They are not a separate engagement and they are not something an SEO consultant raises three weeks after you go live.
You get the repository
Every project ends with the code in a repository you own, with a readable commit history and a README that tells a developer how to run it. No licence conditions of ours attached to it, and nothing in it that only works while we are involved.
03Engagement
How a build runs
- 01
Scope. We agree what it does, what it does not do, and what we have assumed. In writing. If something in the brief will not work, you hear it here rather than in week six.
- 02
Build. Work goes into your repository in reviewable pieces, on a fixed check-in rhythm, with one named contact. You can see it running on a staging URL from early on.
- 03
Test. Functional testing, real devices, accessibility and performance checks against the budget agreed at scope.
- 04
Launch. Redirects, analytics, monitoring and search-console setup are part of launch day, not a follow-up ticket.
- 05
Handover. Documented, deployed and walked through with whoever is taking it on.
04After launch
What happens after launch
The code is yours and you are not locked in. If you would rather we kept running it, support and maintenance and hosting are separate, optional agreements — and remain optional.
Applications are different from sites in one respect worth saying plainly: software that is used every day will need changes. We would rather agree how those get requested and paid for before launch than have that conversation for the first time when something is urgent.
05Proof
Selected work
Placeholder — invented projects, pending real client work
Meridian Freight
Booking and tracking for a haulier whose customers were phoning to ask where a load was. The integration work was most of the job.
Portal + carrier API integrations · 2025Northbank Studio
A WordPress site kept as the editing surface and a new front end put in front of it, because the editors did not want to learn a second tool.
Headless build · Nuxt + WP REST · 202606FAQ
Questions we get asked
Do we need an application, or will a website do?
Usually a website with two good forms. We will say so if that is the answer — it is a smaller project, and telling you that at the start is worth more to us than the difference in fee.
Who owns the code?
You do, from the first commit. The repository is yours.
Can our own developers work on it afterwards?
That is what the handover is for. Documented setup, deployment instructions, environment variables, and a walkthrough call with whoever is taking it on.
Do you work with our existing hosting?
Yes, in most cases. If the hosting is the reason the site is slow or keeps falling over we will tell you, and moving it is a decision you make rather than one we make for you. See hosting.
What if we already have a half-finished build from someone else?
Send it. We start with a written assessment of what is there, what is salvageable and what is not, before anyone commits to finishing it or restarting it.
How do you handle changes mid-project?
Anything outside the written scope comes back to you as a short note with the cost and schedule impact before we build it, so it is your decision rather than a surprise on the invoice.
07Next step
Start a project
Tell us what you are trying to build and when it needs to be live. If we are not the right people for it, you will hear that first.
Or email us at hello@felixwebsolutions.com.
Agency looking for a build partner? We work white-label →