I wanted to write a little about how the VeySur survey platform is built and the thinking behind it. When you rely on a piece of software it is nice to know something about where it came from and the motivation behind its creation.
VeySur is a platform for running research surveys. It is built with care, on a foundation meant to stay maintainable over a long life.
What keeps software alive
I have been building software professionally for about twenty years, mostly as a freelance developer, across a lot of different companies. What has held my interest that whole time is not a particular language or framework. It is a simpler question: what keeps a codebase healthy and easy to change, and what turns it into something a team dreads touching.
The cost of software is not writing a feature. It is every change that comes after. Shipping a feature this week feels like progress. The mess left behind to hit that date stays invisible until, a year on, routine work takes far longer than it should and nobody can say exactly why.
Most of what I have learned is about avoiding that. Carry the complexity the problem really needs, and refuse the complexity you create for yourself. Pick tools because they fit the job, not because they are the ones you already know. When part of the system stops fitting, change it rather than pile another workaround on top, and treat the occasional big refactor as a normal part of the work rather than a crisis. Little of this is glamorous. Most of it is judgement: knowing when to leave something alone and when a larger change is worth the disruption, and being willing to correct course when you get that call wrong.
Where VeySur came from
For much of my career I have run into the same wall. The case for testing, for refactoring, for learning from how effective teams work, tends to lose out to the pressure to ship the next thing. The benefit of doing that work is spread out over years, while the cost of skipping it stays invisible until it is a crisis, so it is a hard argument to win.
I had also spent a few years working on software much like this, so I knew the shape of the problem well. At some point I decided I would rather build my own version of it and make the choices I thought were right from the start, than keep making the case for them on someone else’s project.
That did not remove the pressure to produce working software quickly. It just meant that this time it was me deciding what counted as an acceptable short-cut and what did not.
From the first commit in July 2025 to launching the hosted platform in August 2026 took just over a year, working alone.
The work itself
The parts of VeySur I am most pleased with are structural. You never see them directly, but you feel them in software that behaves predictably and keeps improving rather than seizing up. A few of the choices that mattered, in plain terms:
One language, everywhere. The same programming language runs in your browser and on our servers. That sounds like an internal detail, but it means the checks that validate your survey data are written once and used in both places, so they can never quietly disagree with each other.
Mistakes caught before release. The code is written in a style where a large class of errors is flagged automatically, before anything runs, let alone reaches you. It also makes later changes much safer, so fixes and improvements can land without a long nervous wait.
A survey is stored as a survey. A survey is naturally groups of questions, each with its answers. VeySur keeps it in that shape internally rather than flattening it into rows and tables. The software stays close to how you actually think about a survey, which leaves fewer places for bugs to hide.
Changed as a whole, never half-finished. The survey model follows an established design discipline for keeping complicated rules in order. In practice, every change to a survey goes through one controlled path, so it can never be saved in a broken or half-valid state.
One shared vocabulary. The words used with you in support, the words in the documentation, and the names inside the code are all the same. When you report something, there is no translation step between what you describe and what the code calls it.
Built to be tested. From the start, the code was designed so its behaviour can be verified automatically. A large body of tests runs on every change and flags anything that breaks existing behaviour.
Alongside these are many smaller habits: consistent naming, tests kept next to the code they check, design decisions written down as they are made. Individually minor. Together they are most of what keeps a codebase healthy over years.
There are still rough edges, and some areas I would design differently now. That is to be expected.
The bottom line
None of this guarantees good software. But it is the difference between a codebase you can keep improving and one you spend your time fighting. VeySur was created by someone who has spent a long time thinking about that difference, and it will go on being built that way. If you are going to trust a tool with your work, that is worth knowing.