Building BubSync: AI Made the Coding Easier. Everything After Was the Hard Part
I am a Full Stack Developer from Brisbane, Australia . I enjoy learning and sharing my knowledge with others.
As a software engineer, I always assumed that if I ever built my own product, the difficult part would be building it.
Architecture. Authentication. Offline support. Sync. Mobile releases. Infrastructure. AI integrations. All the things engineers spend years learning how to do well.
It turns out I had that almost completely backwards.
Over the past several months, I've been building BubSync, a shared baby tracker and diary designed to help parents, family members and carers stay in sync.
And the biggest lesson I have taken from the experience is this:
Building the software was the easy part. Building a business around the software was much harder.
AI has changed the economics of building software dramatically.
It has not changed the economics of getting anyone to care about it.
The idea
BubSync started from a fairly simple problem.
Baby tracking apps are useful, but many of them are designed around a single primary user.
Real life isn't like that.
One parent records a feed. Another settles the baby. A grandparent looks after them for the afternoon. Someone needs to know when they last slept, what happened during the day, or whether a bottle has already been given.
I wanted to build something around the idea that:
It takes a village. The software should keep that village in sync.
That became BubSync.
The application grew to include shared activity tracking, feeds, sleep, nappies, memories, caregiver handovers and an AI layer grounded in the family's own data.
From an engineering perspective, there was plenty to build.
But the way I built it was very different from how I would have approached a side project even a couple of years ago.
AI changed the development part completely
I started building BubSync heavily assisted by GitHub Copilot.
At first, it felt like having extremely good autocomplete.
Then I started giving it larger pieces of work.
Generate this component.
Write these tests.
Refactor this service.
Help me understand why this React Native behaviour is occurring.
Build the API endpoint.
Write the infrastructure configuration.
The development loop became dramatically faster.
Eventually I transitioned much of my development workflow to Claude, where the shift became even more noticeable.
Rather than working file by file, I could increasingly work at the level of intent.
I'd describe what I wanted, provide the surrounding architecture and constraints, let the AI implement a significant portion of it, then review, test and iterate.
That doesn't remove the need for engineering knowledge.
If anything, experienced developers arguably benefit more because you still need to know:
whether the architecture makes sense
whether the implementation is secure
whether the abstraction is appropriate
what edge cases have been missed
what should and shouldn't be built
whether generated code actually solves the underlying problem
But it changes where the effort goes.
I was spending less time physically producing code and more time designing systems, reviewing implementations and steering the product.
For a solo developer, that's incredibly powerful.
It also creates a dangerous illusion.
You start thinking:
"If I can build this quickly, I can launch a business quickly."
Those are two very different things.
Then you finish the product
Eventually you reach a strange point.
The app works.
Maybe not perfectly. Software is never really finished.
But it works.
And as an engineer, there is a natural instinct to keep improving it.
Add another feature.
Refactor something.
Improve performance.
Fix the edge case that affects 0.2% of users you don't have yet.
Because coding is comfortable.
You know how to do it.
Then you realise the uncomfortable truth:
Nobody knows your product exists.
This is where building BubSync changed from a software engineering project into something much bigger.
You need a web presence
"I'll just make a landing page."
That sounds easy enough.
Until you start asking questions.
What should the headline say?
What problem are you actually solving?
Should the website describe features or outcomes?
How do you demonstrate trust?
What screenshots should you use?
What should the call to action be?
Should someone download the app immediately or learn more first?
What pages does Google expect to see?
Do you need pricing pages? Feature pages? Comparison pages? FAQs?
Suddenly the website is a product of its own.
And unlike application development, there isn't necessarily a correct answer waiting to be implemented.
You have to make judgement calls.
Then measure whether those judgement calls worked.
Then there are the app stores
I'd built mobile applications before.
Publishing one as the owner of an actual business is different.
There are certificates.
Provisioning.
Developer accounts.
Store metadata.
Privacy declarations.
Subscription configuration.
Screenshots for multiple device sizes.
App descriptions.
Keywords.
Content ratings.
Testing tracks.
Review guidelines.
Beta releases.
Production releases.
And then you submit it.
At which point another human being decides whether you interpreted all of the rules correctly.
If you get rejected, you work out why, fix it and try again.
Shipping software through an app store is almost a separate engineering discipline.
And none of it makes your product successful.
It merely grants you permission to compete.
Then you discover that you need a business
Until this point, you can pretend you're building a project.
Eventually money enters the picture.
Now you need to understand things like:
business structures
companies
trusts
trustees
ABNs
GST
business banking
payment processing
invoices
expenses
bookkeeping
accounting
tax
contracts
terms and conditions
privacy policies
insurance
This was one of the more surprising parts for me.
As engineers, we're used to entering new technical domains.
Give me an unfamiliar API and I'll read the documentation.
Give me a new cloud service and I'll work it out.
Legal and accounting systems feel different.
The consequences of misunderstanding something can be much greater than a failed deployment.
And there isn't always a compiler telling you you've done it wrong.
Marketing might be the hardest part
Then comes the word most engineers instinctively recoil from:
Marketing.
I used to think marketing mostly meant advertising.
It doesn't.
Marketing starts much earlier.
It is working out who your product is actually for.
What problem they think they have.
How they describe that problem.
Where they go looking for solutions.
Why they would trust you.
Why they would choose you over a competitor.
What would make them tell someone else about it.
You can build an objectively excellent piece of software and still answer all of those questions badly.
The market doesn't award points for elegant architecture.
Users don't care how clever your backend is.
They care whether the product makes their life better.
That sounds obvious when you write it down.
It is much harder to internalise when you've spent your career being rewarded for solving technical problems.
Then you need traffic
Having a good website isn't particularly useful if nobody visits it.
So I started learning SEO properly.
Not just:
"Put some keywords on the page."
Actual SEO.
Search intent.
Internal links.
Backlinks.
Domain authority.
Structured data.
Page titles.
Meta descriptions.
Canonical URLs.
Indexation.
Sitemaps.
Search Console.
Content clusters.
Topical authority.
Technical SEO.
Page speed.
And then you discover SEO isn't enough anymore.
Now there's AEO, or Answer Engine Optimisation.
You want your content to be understandable not only by traditional search engines, but by AI systems answering questions directly.
Which introduces another set of questions.
How do you become a source that AI systems trust?
How do you structure information so it can be cited?
How important are brand mentions compared with links?
How do you establish entity authority?
How does discovery change when users increasingly get an answer without clicking through ten blue links?
I'm a software engineer.
A year ago I wasn't thinking about any of this.
Now I have opinions about canonical tags.
Backlinks are their own rabbit hole
Eventually SEO leads you to backlinks.
Then you realise the internet has an entire economy built around them.
Directories.
Guest posts.
Digital PR.
Journalist requests.
Podcasts.
Partnerships.
Link exchanges.
Affiliate arrangements.
Sponsored posts.
People emailing you offering 50 backlinks for $19.99.
Websites with suspiciously impressive domain authority scores and articles apparently written for no human audience whatsoever.
And Google sitting above all of it effectively saying:
Please acquire links naturally.
Right.
So you find yourself doing something that feels deeply unnatural to an engineer:
asking strangers on the internet to mention you.
Sales outreach is even more uncomfortable
Engineers are used to building things and letting the work speak for itself.
Businesses don't necessarily work that way.
Sometimes you have to email someone.
Then follow up.
Then follow up again.
You need to contact potential partners.
Publications.
Communities.
Customers.
People who could introduce you to other people.
You start writing messages like:
"Hi, I noticed you recently published..."
And suddenly you're doing sales.
There isn't a unit test for whether an outreach email is good.
You send it.
Then someone either responds or doesn't.
Mostly they don't.
You learn not to take that personally.
You change the message.
You try again.
The hardest shift: from deterministic to probabilistic work
I think this is one of the biggest adjustments for engineers trying to build businesses.
Engineering work is often deterministic.
You fix the bug.
The bug is fixed.
You implement the endpoint.
The endpoint works.
You optimise the query.
The query gets faster.
There are feedback loops and measurable outcomes.
Business-building work is much more probabilistic.
You write an article.
Maybe it ranks.
You contact ten publications.
Maybe one replies.
You post something on social media.
Maybe nobody sees it.
You change your App Store screenshots.
Maybe conversion improves.
You launch a feature.
Maybe nobody cares.
You can execute perfectly and still get no immediate result.
That is difficult when your professional life has conditioned you to expect a fairly direct relationship between effort and outcome.
AI hasn't solved this part
AI has absolutely helped.
I use it constantly.
It helps me:
research unfamiliar domains
write drafts
critique landing pages
analyse positioning
generate content ideas
understand accounting terminology
work through SEO strategies
prepare outreach
analyse competitors
create marketing assets
automate repetitive tasks
But there is an important difference.
With software, AI can often produce the thing.
With marketing, AI can help you produce a thing that might work.
You still need reality to tell you whether it does.
That's why I think the current conversation about AI replacing software development misses something important.
Software production is becoming cheaper.
But software production was never the only constraint.
When almost anyone can build software, distribution becomes more valuable, not less.
Knowing what to build matters more.
Knowing how to reach people matters more.
Having credibility matters more.
Having an audience matters more.
Understanding a market matters more.
The product is only the beginning
One of my biggest lessons from BubSync has been that launching a product isn't:
Idea
↓
Build
↓
Launch
It looks more like:
Idea
↓
Research
↓
Build
↓
Test
↓
Position
↓
Brand
↓
Website
↓
Business setup
↓
Legal
↓
Accounting
↓
App stores
↓
Content
↓
SEO
↓
AEO
↓
Backlinks
↓
Outreach
↓
Distribution
↓
Measure
↓
Learn
↓
Change things
↓
Repeat indefinitely
The application is one component of the business.
For an engineer, it just happens to be the component you're most comfortable building.
What I'd do differently next time
If I started another product tomorrow, I wouldn't begin with six months of development.
I'd spend much more time validating distribution first.
I'd ask:
Where will the first 100 users come from?
Not theoretically.
Literally.
Who are they?
How do I reach them?
What communities are they already part of?
What are they searching for?
Who already has their attention?
Could I build an audience before building the product?
Could I create useful tools or content that attract the same users?
Can I validate that people care enough about the problem before solving every edge case?
Those questions now feel at least as important as:
"What technology stack should I use?"
Possibly much more important.
Build earlier. Market earlier.
There is another trap I fell into that I suspect is common among engineers.
We want to show people something good.
So we wait.
One more feature.
One more polish pass.
One more bug fix.
One more release.
Then we'll start talking about it.
The problem is that marketing itself requires iteration.
Your first landing page probably won't be right.
Your first positioning probably won't be right.
Your first social posts probably won't work.
Your first outreach messages probably won't work.
You have to start failing at those things early enough to learn from them.
If you're building a product, marketing shouldn't begin when the product is finished.
It should begin when the product begins.
Was building BubSync worth it?
Absolutely.
Regardless of where BubSync ultimately goes, I've already learned more from building and launching it than I would have from another dozen technical side projects.
Not because the engineering was uninteresting.
There were plenty of genuinely difficult engineering problems.
But because it forced me outside engineering.
I had to learn how businesses actually operate.
How products are discovered.
How markets behave.
How app stores work.
How search works.
How positioning works.
How difficult getting someone's attention actually is.
And perhaps most importantly:
Building something and building something people use are completely different skills.
AI is making the first one dramatically easier.
I'm increasingly convinced that the second one is where the real challenge now lies.
The lesson I'll carry into the next product
For years, the limiting factor for someone like me was the cost of building software.
You needed time.
You needed engineering skills.
You needed infrastructure.
You needed potentially an entire team.
AI has compressed much of that.
A capable engineer can now build an extraordinary amount of software alone.
That's exciting.
But it creates a new bottleneck.
Attention.
Trust.
Distribution.
Customers.
The ability to turn software into a business.
So if you're an engineer thinking about building your own product, I'd absolutely encourage you to do it.
Just don't make the mistake I did and assume the hard part ends when the code works.
That's when a completely different kind of engineering begins.
