Built to Last

Early in John Leith's career, VirgoDev's codebase had a small, sensible-sounding rule: when the DEBUG flag was switched on, write to the test database instead of the real one. Nobody wants a developer's test order showing up in a real warehouse queue. It's a good rule — right up until the day someone forgets to flip it back off.

That day was John's. He was testing something unrelated, DEBUG stayed on, and real customers kept placing real orders on the live site — except every one of them was quietly writing itself to the wrong database. "It took some work to fix that issue," is about as much drama as you'll get out of him describing it.

Afterward, he decoupled DEBUG from the database entirely and got, in his words, "more thoughtful on what should be an automatic setting." It's a small story. It's also a pretty good preview of the theme running through the rest of this conversation: don't let a shortcut quietly become a load-bearing wall.

John is a Senior Engineer at Virgo Development and, by a wide margin, the longest-tenured person on the team — his history with the company stretches back to its earliest days operating as Velocity Webworks. I sat down with him for VirgoDev's ongoing engineer spotlight series (the first installment featured Senior Engineer Adam Taylor) to talk about solving problems at scale, why more hardware isn't always the answer, and how he uses AI without letting it do his thinking for him. True to form, most of his answers were three sentences shorter, and one joke drier, than I expected.

01 — Where it started

What Chinking Coins and Early Web Sockets Taught a Future Problem Solver

Like a lot of people his age, John got into software because he wanted to make games. He and a friend spent years chasing that dream before, as he puts it, real life got in the way. But game development left a permanent mark on how he approaches everything else he builds: "appearance and performance are very important, and I try to carry that over into the other projects that I work on."

That instinct toward performance shows up as genuine curiosity about the edges of what's possible. Over the years he's picked up unfamiliar tools early and often — Node.js and Web Sockets back when they were new, async Python the moment it landed in Python 3.4, even a small neural network as a search agent "back before AI was put in everything."

"There is always something new, interesting and often timesaving around the corner if you keep your eyes open and care to look."
— John Leith, Senior Engineer

Ask him what's changed the most since he started, and there's no hesitation: AI. "It makes it possible for me, without any previous context of a project, to enter and immediately gain an understanding of what the project is, who made it and why," he says. "It can answer questions of implementation and find problems with barely any effort... an incredible tool that makes doctoral-level knowledge about anything available instantly." What's stayed constant is less about technology and more about the churn of technology itself: no matter how good a tool is, something newer is always coming to replace it. "Though to be fair," he adds, "VS Code has been my mainstay for a long time."

It's when he talks about what he actually enjoys building that his character comes through clearest. His favorite kind of project "seems hard or is beautiful" — his go-to example is a phone case simulation that used a 3D renderer and a physics engine so that loose coins would visibly chink around inside a phone as you tilted it. "It's really simple, but it was fun," he says, undercutting what is, by any normal measure, a genuinely clever piece of engineering.

02 — Specialty & craft

Why "It Gets Hard to See" Is How You Know You've Outgrown Your Software

Ask John what kind of problems he's especially well-suited to solve, and he doesn't reach for anything abstract: speed. "One thing that I've done a lot now, and it makes me really happy when I can do this, is just making something faster," he says. "It's pretty easy to build a data source and use it, but when a site grows, these things often don't scale. It's not something that the creators are always aware will become a problem when it's made."

That's also his answer to one of the more common questions VirgoDev fields from prospective clients: when does an off-the-shelf SaaS tool stop being good enough? John reaches for a metaphor instead of a checklist:

"It's like a pair of glasses. You'll know when you need to change because it gets hard to see. If you find yourself spending a lot of time fighting with the software because it doesn't do what you want, then it's worth checking if the time you save would be worth the cost of something else."
— John Leith, Senior Engineer

The detail he says even experienced developers get wrong sits one layer beneath that: how the data itself is shaped. "Perhaps data normalization," he offers. In plain terms: it's common to build a "Parent" record with fields for "Child name 1" and "Child name 2" — which works fine until a third child shows up and the table needs another column. The fix is to give children their own records that simply reference the parent, so there's no built-in limit.

He's careful to note this isn't a beginner's mistake. "Sometimes even experienced coders create data normalization issues — it's a tough problem," he says. "It's hard to know what to do about it sometimes. You'll have to think through the forms that your data will take and make sure that they relate correctly." Get it wrong, and the mistake doesn't stay contained: "Generally speaking, everything on the site is based on the database. If the shape of the data is malformed, the site will also be malformed."

It's a problem with a real price tag attached, even when nobody's tracking it. Gartner estimates poor data quality costs the average organization $12.9 million a year in wasted resources, lost opportunities, and operational drag — and a shortcut like the one above is exactly the kind of decision that compounds quietly for years before anyone traces it back.

03 — The case study

Inside the Order-Processing Problem That Taught Him the Most

Ask John for the project he's most proud of, and he goes straight to a site that was processing around 20,000 orders a day — the bulk of them landing within just a few minutes of each other — against an old datasource that was, in his words, "notoriously slow."

The instinctive move, and the one clients often suggest first, is to throw more hardware at it. John doesn't dismiss that instinct outright — sometimes it's the right call. But in this case, the math didn't cooperate.

"If you have one server that can process 4 orders at a time, that takes 83 hours. You are going to be drowning in order processing. You'd actually need 100 computers with 20 cores each to process all of that in 10 minutes. And if you think about the data source that will get all of these orders coming in, well, they'll probably need to buy more computers too."
— John Leith, Senior Engineer

So, he and the site's owner iterated toward something else entirely. They deferred the slow data source until it was actually needed, added aggressive caching, and — in the piece of the puzzle John still sounds pleased about — began writing new orders to their own high-speed internal datastore first, syncing everything to the legacy system afterward in a steady stream, while the site wasn't at peak demand.

"It felt good to be able to get that many orders processed daily without getting a phone call," he says — which is, in three sentences worth of subtlety, about as close as he comes to bragging.

It's also a pattern he sees constantly in how clients describe problems versus how those problems actually get solved. "The way I prefer to do this is to get as much information about the project first," he says. "Then map out what will be done and start iterating on it. I want to show the client the visual side of it as soon as possible so they can see if it is turning out how they expect. Ultimately, we can't read minds, but by involving the creator with the creation we can try to get it as close as possible to the vision."

04 — Technology, AI & change

The One Rule John Follows With AI: It Doesn't Grade Its Own Homework

John's take on AI is refreshingly free of hype in either direction. Async processing was, in his telling, the last technology shift that genuinely changed his day-to-day work — "the true solution to efficiency, since it transforms IO operations like writing to a disk or the internet into additional processing time," as he puts it. "But in the last two years, AI has surpassed even that. It makes finding things and doing large transformations simple."

He uses it constantly and trusts it selectively. It's very good, he says, at finding things from vague instructions — the kind of half-remembered request that used to cost twenty minutes of digging. But he's also watched AI take shortcuts on more complex work, and he's read the research suggesting heavy reliance on AI can quietly erode independent thinking over time. His response is a simple operating rule: AI should do testing or implementation, but not both on the same piece of work. "I have seen AI try to shortcut to make something quick," he says, "so I always read the code and try to understand it before releasing it."

The industry data explains why that discipline matters well beyond VirgoDev. In the 2025 Stack Overflow Developer Survey, 45% of developers named debugging AI-generated code as one of their biggest day-to-day frustrations — a near-perfect argument for John's rule that the same tool shouldn't both write the code and be trusted to check it.

That same skepticism-without-cynicism shows up when I ask what current trend he thinks is overhyped or misunderstood. His answer: WordPress. Not because it's bad software — "WordPress is a really great framework that lots of people use," he says — but because of what sits underneath it. "It is, however, built on a language (PHP) that has historically had a lot of security issues and continues to have them. The fact that it's popular makes it a target for hackers. The fact that it's had security issues makes it easier for hackers." His advice isn't to avoid WordPress; it's to "keep it up to date."

The 2026 numbers back him up. WordPress still accounts for roughly 90% of hacked content-management-system websites, and security researchers logged more than 11,000 new WordPress vulnerabilities in 2025 alone — the large majority traced back to outdated plugins rather than WordPress core itself. It's exactly the pattern John describes: popularity plus patching discipline, or the lack of it, decides the outcome.

The last shift he mentioned almost as an aside is probably the most consequential for how he actually builds things day to day: "I tend to think mobile first now, since phones are more typically used than desktops."

05 — Philosophy & advice

What Separates a Good Engineer From a Great One

People often assume the best engineers fit a certain type: "super smart and socially awkward," as John puts it. You do need people like that, he says — they're often the ones capable of the genuinely complicated work. But there's a ceiling on how much that talent alone is worth.

"The great engineers have the talent of the nerds and are still able to communicate well. They are the ones that listen and understand. It doesn't do you any good if you commission a project and the result isn't what you wanted. So, it really doesn't matter if the engineers are smart unless they are building in the right direction."
— John Leith, Senior Engineer

That philosophy extends into how he thinks about tradeoffs between speed, budget, and long-term reliability — and it's where the title of this piece comes from. "If you make something, I think you should make it so that it will last," he says. "If you chase a trend, I guess it doesn't matter how good your site is — that's fine if you want to do that. But if you are making something useful, then you should build it to last. That means using best practices, testing, and making readable code so that it can be maintained through its life."

He's equally candid about where client expectations tend to go sideways — starting with what people assume custom software will cost in time. "Fixing something that exists takes less time than making something new," he says, "but existing software must first be understood in order to make changes." And he pushes back gently on one of the more popular assumptions of the moment: that AI collapses that timeline to almost nothing. "This is at least partially true, but it has the same problem as above: in order for us to be sure the code does what it should, we need to read and understand what is being built. It takes less time than building from scratch, but it doesn't eliminate all the effort that needs to be performed to make a project live."

If he could get in front of a business owner before they spent the first dollar on a project, his ask is simple: get specific first. "The best requests I've gotten from clients and customers are very clear," he says. "The best of the best was drawn out so I could more clearly understand exactly what they wanted. They thought through their own ideas enough to iron out the wrinkles." That said, he's not asking anyone to show up with a finished spec — "that's not to say you can't approach with a half-formed idea, but then the first time we meet, I'm going to want to try to flesh the idea out."

06 — Off the clock

The Redraft: What Creative Writing Taught Him About Engineering

Outside of software, John still writes fiction — a habit he credits with sharpening a skill that's easy to undervalue in engineering: the willingness to redraft.

"In order to have a compelling plot, you need to think the story through over and over until the obvious problems are gone. Then you go over it again and again to match the theme. There is a lot of redrafting in order to get it right."
— John Leith, Senior Engineer

Then, almost as a throwaway line, he adds the sentence that ties this whole conversation together: "We probably should do more of that in engineering too."

It's the same instinct that shows up in the DEBUG flag story from the start of his career, in the order-processing system he's most proud of, and in his rule about never letting AI write and check its own work. Nothing gets built right the first time. The job is noticing that — and being willing to go back through it again.

07 — Common questions

Quick Answers

Honestly, reviewing these questions with John is a good reminder of what's actually held Virgo Development together across all these years since its Velocity Webworks days. It's not a single technology or a clever trick — it's people who default to fully understanding a problem before they touch it, and who are willing to redraft until the fix is actually right, not just technically shippable. Whether that shows up as a 20,000-order system that doesn't wake anyone up at 2 a.m., or a database schema built to survive a business growing in directions nobody predicted, it's the same instinct at work.

If your software is starting to feel like a pair of glasses you've outgrown, that's usually the sign it's time for something built to last.

Ready to talk through what that could look like for your business? Book a Discovery Call with me and the team.