Real developers. Real journeys. Real lessons.
Brent Vardy has been writing software for more than four decades. His journey started with a Commodore VIC-20 and 5KB of RAM, continued through decades of professional software development, and has now led him toward a very different goal: building his own products as a solo indie founder.
Interview & Story by Mehadi Hasan
It Started With a Commodore VIC-20
Brent Vardy's programming journey began around 45 years ago.
In late 1981, when he was nine years old, he received a Commodore VIC-20 home computer.
There wasn't much software available, and what was available was too expensive for a nine-year-old.
But Brent already had an interest in something that would eventually shape his approach to software: adventure books.
These weren't ordinary books. Readers navigated them by answering questions at the bottom of each page, with their answers determining which page they should read next.
So Brent decided to recreate that experience on his VIC-20.
The computer came with Commodore BASIC 2.0, and he used it to turn some of his adventure books into interactive games.
All of this ran in just 5KB of RAM.
There was no GitHub.
No cloud storage.
No source control.
Brent stored his code on a tape recorder through a serial cable.
And sometimes, he lost the code and had to type everything again from scratch.
That early experience taught him something that would stay with him for decades: he loved creating small, useful applications.
From School Projects to Building Useful Software
After the VIC-20 came a Commodore 64 and then an Acorn Electron.
Brent was also part of one of the first classes at his school to be offered Computer Studies.
Around the same time, CD players were becoming popular in the UK.
His father was an electrical engineer and music lover, so Brent decided to build a school project around CD players.
He created an application that stored information about the different manufacturers and models available at the time, including specifications and prices.
He didn't call it a database.
Technically, it was an application with all the information hardcoded into the program and loaded into memory.
If a new CD player appeared, Brent had to modify the source code, save it back to tape and reload the application.
But the important part wasn't the architecture.
It was the experience of building something useful.
“Building this hooked me and started my love of creating small useful applications.”
That idea would eventually become a recurring theme throughout Brent's career.
Decades of Building and Experimenting
Brent's path wasn't a straight line toward entrepreneurship.
Over the years, he worked on many side projects with friends and colleagues.
Not all of them worked.
In fact, Brent openly describes having built several products that ultimately failed.
But the failures didn't remove his desire to build something of his own.
They became part of the learning process.
He continued experimenting, learning new technologies and creating software for himself, his family, friends and colleagues.
Some projects were practical.
Others were simply for fun.
The important thing was that he enjoyed the process of building.
From Corporate Developer to Indie Founder
The idea of seriously building his own products began to take shape in 2026.
Brent had been thinking about semi-retirement and wanted to create something that could support that lifestyle without requiring him to access his pension early.
He had already been working on a meditation application for himself.
Instead of keeping it as another personal project, he decided to see whether it could become his first product.
This time, however, he approached things differently.
He registered a company first.
That company became Code and Sea.
The name reflects a personal goal shared by Brent and his wife: eventually moving to the coast and creating a lifestyle with more freedom and flexibility.
Code and Sea is his attempt to build toward that future through software.
When Building Became More Personal
For Brent, becoming an indie developer isn't simply about escaping a corporate job.
It's about gaining control over how he spends his time and energy.
After many years in a corporate environment, he wanted greater flexibility to decide what he worked on, when he worked and which projects deserved his attention.
That became particularly important because managing his available energy is a significant part of his day-to-day life.
Building software can be demanding, but Brent also describes coding as an escape.
When his physical energy is low but his mind is clear, writing code gives him a way to solve problems, create things and feel productive at his own pace.
That has also influenced how he thinks about features.
He has become much more selective about what he builds.
And that constraint has turned out to be useful.
The Push Into Indie Development
Brent had spent 28 years with his previous company when he was told in September 2026 that his role would end at the end of the month.
It was a shock.
There was uncertainty about what would happen next.
But Brent doesn't describe the experience with bitterness.
Instead, after accepting the decision, he began seeing it as the push he needed.
He had spent 28 years learning, developing skills and building relationships.
Now he had an opportunity to finally pursue something he had wanted to do for years.
From October 1, Brent would have much more control over the decisions and direction he took.
Successful or not.
Why Code and Sea Exists
Code and Sea isn't being built around the idea of creating the next huge technology company.
Brent's motivation is much more personal.
He wants to build products he enjoys, generate enough revenue to support his lifestyle and eventually move toward a slower life by the sea.
He is also building products based on problems he personally experiences.
That philosophy is visible in his growing backlog of product ideas.
Many of them come from applications he already uses but doesn't completely like.
Sometimes they're too complicated.
Sometimes they include features he doesn't need.
Sometimes they require a subscription for functionality Brent doesn't want.
His response is simple:
Build his own version.
Mantra Meditation Timer: Building What He Actually Needed
One of those ideas became Mantra Meditation Timer.
Brent had been using meditation applications for many years but couldn't find one that worked exactly the way he wanted.
He found many meditation apps distracting.
Notifications.
Social features.
Content feeds.
Recommendations.
Too many things happening when he simply wanted to meditate.
So he built his own.
The goal was intentionally simple:
Open the app.
Start the meditation.
No distractions.
No social feed.
No unnecessary information.
Just the tools needed for his personal practice.
Interestingly, Mantra Timer wasn't actually Brent's first attempt.
It was the third meditation application he had built.
The first two were more like clones of existing mainstream apps.
Eventually, he realized that copying what other applications were doing wasn't the answer.
He only needed the features that mattered to him.
So he stripped the idea back.
And something unexpected happened.
Other people felt the same way.
When Real Users Changed the Product
Brent initially believed he might be the only person who would use Mantra Timer.
He was fine with that.
Then people started asking to become beta testers.
He created a form on his website.
People signed up.
And the feedback turned out to be extremely valuable.
The experience changed his view of product development.
Real users exposed problems and opportunities that Brent couldn't have discovered simply by building alone.
His advice to founders is straightforward:
Get real users involved early.
Feedback can be uncomfortable.
People will criticize things you've spent hours building.
But that criticism can also produce a much better product.
For Brent, the beta programme became one of the most important parts of getting Mantra Timer ready for release.
Learning to Ship Before Everything Is Perfect
One of Brent's biggest lessons from building Mantra Timer was that building the product isn't necessarily the hardest part.
Shipping is.
“Building the product is easy, having the confidence and knowing when to ship is hard.”
Having around 15 active beta testers gave him confidence that the product was solving a real problem.
It also gave him people who were using the application regularly and could identify issues before public release.
That experience changed his attitude toward perfection.
Brent became more comfortable sharing a product earlier, even if it wasn't completely polished.
If the product is usable and testers understand that they're using an early version, polish can come later.
The important thing is to discover whether the product actually solves the problem.
The Lesson From Failed Projects
Brent has built several projects over the years that never became successful products.
Two examples he mentions are LocationCounts and UKMapfinder.
In both cases, he started with a problem he wanted to solve.
Then something happened that developers know very well.
He kept adding features.
The projects became bigger.
The software became more complicated.
But the products weren't being tested with real users.
Eventually, they launched and simply died.
That experience taught Brent something important about product development.
More features don't necessarily make a product better.
In fact, limiting features can be an advantage.
A smaller product is faster to launch, easier to maintain and easier for users to understand.
Choosing Technology Without Chasing Trends
Brent has worked with a remarkably broad range of technologies over the years.
His experience includes:
- Swift
- SwiftUI
- SwiftData
- PHP
- Laravel
- Livewire
- TailwindCSS
- AlpineJS
- Python
- Ruby
- C
- C++
- Java
- Objective-C
- Delphi
- Node
- Golang
- And many others
These days, he generally uses PHP and Laravel for web applications, Python for automation and command-line tools, and Swift for Apple platform development.
But Brent doesn't choose technology simply because it's the newest thing.
He prefers technologies he already knows and trusts.
If his preferred stack can solve the problem, he will usually stick with it.
“My opinion is the final product is more important than the actual stack used.”
It's a practical philosophy developed through decades of software development.
Why Swift and SwiftUI?
Brent particularly enjoys Apple's development ecosystem.
One reason is access to Apple's native APIs.
Instead of depending heavily on third-party plugins, he can work directly with Apple's platform capabilities.
He also appreciates services such as iCloud and Maps, which can be integrated into applications without the same kind of usage-based costs that some third-party platforms introduce.
He likes the documentation and believes native Swift applications can provide a particularly good user experience.
For his current product direction, Swift and SwiftUI make a natural fit.
The Reality of Being a Solo Founder
Being a solo founder means doing much more than writing code.
Development is only one part of the job.
There is:
- Product development
- Design
- Marketing
- Distribution
- Customer discovery
- Testing
- Support
- Business decisions
Brent is comfortable with most of these areas.
The two areas he says he needs to improve most are design and marketing.
Now that he has more time available, those are areas he plans to focus on.
He also prefers learning and doing things himself rather than immediately outsourcing them.
But he's beginning to recognize that there may be situations where outsourcing is simply the pragmatic choice.
From Developer to Product Builder
Building products for himself and for corporate users was different from building something that strangers are expected to pay for.
When building internal software, there is often an existing specification.
When building a personal project, the requirements can come directly from your own needs.
But when you're asking the public to spend money, every decision becomes more important.
Brent says Mantra Timer taught him to get products in front of users quickly and genuinely listen to what they say.
That represents a significant change in his approach to software.
Instead of spending months trying to make something perfect before showing anyone, he now sees real-world feedback as part of the development process itself.
What Does Success Mean to Brent?
Brent has a realistic definition of success.
He isn't necessarily trying to build a huge company or reach the kind of revenue numbers frequently shared in indie-founder communities.
For him, Code and Sea is about creating a sustainable life around something he enjoys.
If the business eventually generates around £20,000 per year, he would consider that a success.
But the money isn't the only measurement.
Success also means:
- Having control over his time
- Continuing to build software
- Keeping his mind active
- Helping and supporting other people
- Creating products he enjoys
- Building toward a life by the sea
For Brent, the journey matters as much as the destination.
Building in Public Doesn't Automatically Mean Customers
Brent has also learned something important about building in public.
Sharing your work doesn't automatically produce customers.
At least, it hasn't done so for him yet.
But that doesn't mean building in public has been a failure.
Quite the opposite.
It has helped him meet other founders and developers who have become valuable sources of advice, testing, launch support and encouragement.
Running a solo business can be lonely.
Having other people who understand what you're going through can make a significant difference.
Brent particularly values the relationships he's developed with other founders through this process.
Why CoderLegion Matters to Brent
Brent joined CoderLegion because he enjoys seeing what other developers and founders are building.
He also made a conscious decision to support other independent developers whenever possible.
If he needs an application or service, he tries to consider products created by people in similar situations.
His hope is that this kind of support can eventually be paid forward.
He describes CoderLegion as welcoming and appreciates its more down-to-earth atmosphere.
Compared with some other indie communities, he feels CoderLegion is more realistic for developers who are still building their businesses and haven't reached huge recurring revenues.
That's important to him.
He doesn't want unrealistic expectations.
He wants a community where developers can share what they're actually doing.
“I want to stay firmly on the ground and realistic.”
What's Next for Code and Sea?
Brent currently has several products in development.
His immediate focus includes adding additional language support to Mantra Timer and preparing a TestFlight beta for its watchOS version.
He's also continuing work on Tidal Draft, another product based on a problem he personally encountered.
Tidal Draft is intended to provide an alternative to an existing product that Brent uses but feels charges a subscription for functionality he doesn't need.
His version will use a pay-as-you-go model.
He plans to begin inviting people into a private beta and eventually launch Tidal Draft on CoderLegion for users to test.
Beyond that, Brent has a backlog of product ideas he wants to explore.
His goal for the first year is relatively simple:
Release one or two products that generate enough revenue to cover the costs of running Code and Sea.
Then build from there.
One Unexpected Setback
Brent's journey also demonstrates that indie development rarely follows a perfect timeline.
Mantra Timer was originally called Trancendence.
Just hours before the first version received App Store approval, Brent was contacted by a legal firm representing the Maharishi Foundation.
They raised concerns about the app's branding and trademarks.
Brent couldn't afford a legal fight, so he rebranded the application.
The unexpected change took considerably longer than planned.
It's another example of something that doesn't appear in a coding tutorial:
Building a product means dealing with everything around the code as well.
What Brent Would Do Differently
If Brent could go back and change one thing about his indie journey, he wouldn't choose a different programming language or framework.
He would simply start earlier.
And he would release earlier.
His biggest lesson is that waiting until a product is polished can delay the most valuable thing a founder can get:
real user feedback.
“Get it out there as soon as possible to get real user feedback.”
Brent's Advice to Developers Thinking About Going Indie
Brent's advice is practical rather than glamorous.
First, be realistic.
Building your own products is hard.
You will fail.
Probably more than once.
He recommends having a financial cushion — around 12 months if possible — so financial pressure doesn't constantly distract you from building.
He also recommends avoiding the temptation to chase every new technology.
Use proven technologies with strong communities, documentation and available information.
Then get your product into the hands of real users as early as possible.
Find trusted people who will actually test it.
Listen to their feedback.
Use that feedback to determine whether the product is worth continuing.
And don't expect instant traction.
Give the product time.
“If nothing happens immediately keep going, give it a chance before quitting and moving to the next thing.”
From 5KB of RAM to Building His Own Future
Brent's developer journey spans an extraordinary amount of technological change.
He started with a Commodore VIC-20 and 5KB of memory.
He stored code on cassette tape.
He built simple applications because he wanted to make something useful.
Decades later, he's still doing essentially the same thing.
The tools have changed.
The platforms have changed.
The scale has changed.
But the motivation hasn't.
He still enjoys taking an idea, turning it into software and seeing whether someone finds it useful.
The difference now is that he's building toward something much more personal.
Code and Sea isn't simply another software company.
For Brent, it's an attempt to design a different way of working and living — one where he can continue creating software, support himself, help others and eventually build the life he and his wife have imagined by the sea.
And perhaps that's the most interesting part of his journey.
After more than four decades of programming, Brent isn't finished building.
He's simply building for himself now.
About Brent Vardy
Brent Vardy is a UK-based software developer and the founder of Code and Sea, a solo indie venture focused on building practical software products.
His technology experience spans decades and includes Swift, SwiftUI, SwiftData, PHP, Laravel, Livewire, TailwindCSS, AlpineJS, Python and many other technologies.
His current projects include Mantra Meditation Timer and Tidal Draft.
You can connect with Brent on CoderLegion.
Developer Stories at CoderLegion
Developer Stories is a CoderLegion series featuring real developers and their journeys — the projects they build, the challenges they encounter, the lessons they learn and the decisions that shape their careers.
There isn't one correct path into software development.
Some developers start at university.
Some teach themselves.
Some build companies.
Some build small tools for themselves.
And some, like Brent, have been building software since the days when 5KB of RAM was enough to get started.
Interview & Story by Mehadi Hasan
CoderLegion Community & Editorial Team
Want to share your own developer journey?
If you have a story, project, career transition or learning experience you'd like to share with the CoderLegion community, we'd love to hear from you.
