Development Update: The Long Road to vamsys.co.uk

I've been heads-down on vamsys.co.uk for the past week, and it'll likely be another week before I'm back to core vAMSYS development. I wanted to explain what's happening and why this is actually a good investment of time rather than a distraction.

The Original Scope

The initial plan was straightforward: refresh the marketing website and eliminate legacy dependencies on an old server provider that was running our monitoring software and original ticketing system. Simple housekeeping. Modernise the public face, cut the old infrastructure loose, move on.

Even that "simple" part turned out to require more thought than I'd anticipated.

Choosing Statamic 6

The timing worked out well. Statamic 6 had just reached stable release at the time of writing this, and it's exactly what a marketing site needs - a flat-file CMS built on Laravel where content lives as Markdown and YAML files, version-controlled in Git alongside the code. No database overhead for content, no complex deployment pipelines, no worrying about content and code getting out of sync. When I push to main, everything deploys together.

For a site that doesn't need user-generated content or complex workflows, flat-file is the right architecture. It's fast, it's simple to reason about, and it means I can edit content in my IDE (PHPStorm, if you're curious) or the control panel - whatever fits the moment.

Blade Over Antlers

Statamic ships with its own templating language called Antlers. It's designed specifically for content-focused sites and has some elegant features for looping through collections and rendering fields. The Statamic community largely uses Antlers, and the documentation leans that way.

I chose Blade instead.

I've actually used Antlers before - built a customer project entirely in Statamic with Antlers-only templates. It's not a foreign language to me (unlike Pegasus, which is written in magic code). But the mental cost of switching between Antlers and Blade was noticeable. Every day I write Blade templates for vAMSYS, work with Laravel's component system, use its directives. Antlers meant context-switching - different syntax, different conventions, different solutions to the same problems.

Statamic supports Blade fully. You can use @extends, @include, @foreach, all of it. For Statamic-specific features like collection queries and navigation, there's a Blade component syntax (<s:collection>, <s:nav>) that feels native.

What really solidified the choice was Livewire. The status page needed real-time updates - polling server health, refreshing without page reloads. Livewire makes that trivial in Blade. Trying to integrate Livewire components into an Antlers-based site would have been painful. Once the status page was built, any thought of "maybe I should've stuck with Antlers" disappeared.

The result is a codebase where everything feels familiar. No mental overhead switching between vAMSYS and vamsys.co.uk. Same patterns, same muscle memory, same tools.

Design That Doesn't Look Like a Template

I built the site from scratch rather than starting from a theme. The dark aesthetic appeals to me personally - it's the direction I want to take design in general. Premium, distinctive, unapologetically different from the sea of white-background SaaS marketing sites. The glass-effect cards, the subtle ambient glows, the interactive feature images that respond to hover and tap - these choices make vamsys.co.uk stand out.

This isn't about matching vamsys.io. If anything, it's the opposite - vamsys.co.uk represents where I want our design language to go. The current vAMSYS platform was built years ago; when we eventually rebuild it, I hope we'll adopt this more modern aesthetic. The marketing site is a preview of that future.

Building a component library took time. Getting typography right, making sure everything works on mobile, optimising performance. The aircraft animation on the homepage went through several iterations. But the alternative - a generic template that looks like every other SaaS site - would have undermined the premium positioning we're aiming for.

Finding the Brand Voice

This is where I spent more time than I expected. And it might be the most valuable work I did.

I use AI to help with development - not just code, but copy too. At 3am when I've finally figured out how a feature should work, I'm not writing polished marketing text. I'm jotting down rough ideas, bullet points, stream-of-consciousness explanations. AI helps translate those musings into proper copy.

The problem? AI left unchecked writes like AI. Generic. Safe. Full of words like "powerful," "unrivalled," "cutting-edge," "world-class" - empty superlatives that litter SaaS marketing and mean absolutely nothing. If a feature is genuinely good, describe what it does. Don't just call it "powerful" and move on.

So I documented how vAMSYS should sound. Confident but not boastful. Technical but not alienating. Enthusiastic about aviation without being salesy. We know our audience - we don't need to over-explain, but we also don't assume everyone's a veteran simmer.

The brand voice guide covers headline style, feature descriptions, error messages, even how to talk about competitors (respectfully, or not at all). It's a set of rules that keeps AI in check - so when it helps polish my rough ideas, the output still sounds like me. The result is a site that sounds like one person wrote it, because effectively, one person did.

Search Optimisation and Technical Details

The site needed to be discoverable. That meant proper structured data (schema.org markup on every page), semantic HTML, careful meta descriptions, a sitemap, performance optimisation. And because we're apparently all in on the AI craze now, there's an llms.txt file with complete documentation - the idea being that AI agents might eventually discover it, scrape it into their training data or whatever, and start speaking about vAMSYS with a bit more confidence. We'll see.

None of this is glamorous work, but it's work that compounds. Every improvement to discoverability means more people looking to start a Virtual Airline find us without me having to actively market.

Performance: Glide, SSR, and Perfect Lighthouse Scores

Performance wasn't an afterthought - it was a requirement. The site achieves perfect Lighthouse scores, and that took deliberate effort.

For images, I'm using Glide - Statamic's built-in image manipulation library. Every image gets automatically resized, converted to WebP, and served at the exact dimensions needed. No more loading a 4000px hero image on a mobile phone. Glide handles the heavy lifting: responsive srcsets, lazy loading, quality optimisation. The result is images that look sharp but download fast.

The real speed comes from Statamic's static site generation. Pages are pre-rendered as static HTML during deployment - no PHP execution, no database queries, no waiting for the server to build the page. When you visit vamsys.co.uk, you're getting a static file served directly from the edge. It's as fast as a website can possibly be.

This isn't just vanity metrics. Fast sites rank better in search. Fast sites convert better. Fast sites feel premium. When your marketing site loads instantly, it sets expectations for the product itself. vamsys.co.uk now sets a benchmark I'll have to meet with vAMSYS in the future - no pressure.

Testing (A Reluctant Conversion)

I'll be honest: I hate writing tests. It feels like doing the work twice - once to build the feature, again to prove it works.

But vamsys.co.uk has tests. Every future project will too.

Not because I've embraced test-driven development - I still can't get behind writing tests before the code exists. But tests for regression catching? That I understand. When you change something in one place and break something elsewhere, tests catch it before users do. That's worth the upfront investment.

Statamic and Laravel make testing straightforward. Pest keeps the syntax clean. I'm not sold on the TDD philosophy, but I'm sold on not shipping broken features. Maybe that's the first step toward enlightenment. Maybe not. Either way, the tests exist.

All of that was just the website refresh - the "simple" part. Then scope crept further.

Scope Creep (The Good Kind)

When I migrated server monitoring to NetData, I discovered their API is genuinely excellent. That opened the door to building a proper status page - something I'd wanted but never had the infrastructure for. It wasn't planned, but it added real value, so I built it.

Then there's Featurebase. I've been increasingly frustrated with it. For what I pay, I expected it to fully replace both Vision and the ticketing system. It hasn't. Tickets still don't work the way I need them to. The SSO model is all-or-nothing - I'd prefer documentation to be publicly accessible while keeping bug reports and feature requests behind a login, but that's not possible. Duplicate detection for submissions? Locked behind an even more expensive tier. Users can submit bug reports with completely empty descriptions, resulting in posts that tell me nothing. Featurebase bridged a gap when I needed it, but it's not a long-term solution.

Since I'm running on Statamic, managing long-form content is straightforward. Moving documentation in-house made sense. And now I'm implementing Typesense for search - which is where things get genuinely exciting.

Semantic Search, Ask AI, and Why Visibility Matters

The new documentation system isn't just keyword matching. It's semantic search - it understands what you're looking for even if you don't use the exact terminology. Search for "how do I track my flight" and it'll surface ACARS articles even though they don't contain those precise words.

I'm also adding an Ask AI feature. Yes, Featurebase has this too - but theirs is a black box. I have zero visibility into what questions people ask, what answers they receive, or whether those answers are actually helpful.

When you run search infrastructure yourself, you get data. I'll see exactly what people are searching for and, crucially, what searches return poor or no results. That tells me where the documentation gaps are. Instead of guessing what articles to write, I'll know what questions people are actually asking. I can identify where the AI struggles, which questions come up repeatedly, and tune the system to give better responses. It's the difference between renting a tool and owning one.

What's Next: Dropping Featurebase

This is where Typesense really starts to pay off. The same semantic search that powers documentation will extend to bug reports, feature requests, and suggestions.

Back in 2022, Vision - our original bug tracker and feature request site - had basic duplicate detection using Elasticsearch. When you submitted a post, it would show similar articles. Emphasis on basic: no language models, no synonym matching, probably didn't even handle spelling errors. Pure keyword matching. But it was something.

Featurebase was a necessary step. It modernised the experience, added voting, improved search, gave us a more pleasant UI. But the cost isn't worth what we get - and duplicate detection? Locked behind an even more expensive tier with their AI helpers. So we have nothing. Someone reports "the map doesn't load" and someone else reports "world map shows blank screen" - same bug, but Featurebase doesn't see it. Merging similar posts becomes a time-consuming affair.

When I started exploring Typesense's semantic search, it was genuinely an eye-opening moment. This isn't just better Elasticsearch. With vector embeddings, the system understands meaning, not just keywords. Those two map reports? Related. Automatically. Fewer duplicates means popular requests actually look popular, not scattered across five slightly-different posts.

The same technology helps with categorisation. When someone submits feedback, Typesense can suggest which category it belongs in, surface similar existing posts, and even identify if it's a bug report disguised as a feature request (or vice versa). Less manual triage for Team vAMSYS, better organisation for everyone.

Our yearly subscription expires in April, and the plan is to have an in-house replacement ready by then. Ambitious? Probably. But the foundation is already there - Typesense, the search infrastructure, the Statamic content management. I'd rather build something that works exactly how I need it than keep paying for something that doesn't.

Don't worry - all existing posts will be transferred over, just like when we migrated from Vision to Featurebase.

There's something funny about this journey: in-house solution, to third-party service, back to in-house. Full circle. But that's vAMSYS - we iterate, we learn, we try to make things better. Right now, this approach seems better. Ask me again in two years.

What This Means for vAMSYS

Two weeks focused on vamsys.co.uk isn't time lost from vAMSYS development. It's infrastructure that pays dividends:

• A better marketing site means more people looking to start a Virtual Airline discover us
• Searchable, AI-assisted documentation means fewer support tickets asking questions the docs already answer
• Visibility into search patterns means documentation that addresses real user needs
• Less time answering repeat questions means more time on actual development

The Technology Landscape Has Changed

What I'm building now simply wasn't practical two or three years ago. Running semantic search with vector embeddings required expensive GPU infrastructure or slow, inadequate alternatives. AI-assisted search meant eye-watering API costs. Today, a server with the right CPU instructions handles the embeddings locally, and OpenAI's mini models make the Ask AI feature cost virtually nothing - fractions of a cent per query.

The economics have shifted dramatically. Capabilities that were enterprise-tier expensive are now accessible for small teams willing to build rather than buy.

Current Status

I'm currently waiting for the new search server to be provisioned by our provider. Once that's online, I can deploy Typesense and start indexing documentation. The old ticketing system continues running in the meantime - it works, and replacing it isn't urgent.

The remaining work for next week is finishing the documentation migration. After that, the hope is to get back to the Hangar v2 rebuild - which has been waiting patiently in the background.

The longer this project runs, the more confident I am that the extended timeline is creating genuine long-term value rather than burning opportunity cost. Sometimes the slow path is the right one.