I Just Wanted to Sell Honey.
Then I Found CloudFormation.

OnliHoney started with bees.

I had taken up beekeeping as a hobby and, like many hobbyists before me, quickly found myself wondering whether I could sell some of the honey I was producing.

Naturally, that led to another thought.

I need a website.

Shopify looked interesting. Squarespace looked polished. WordPress and WooCommerce were familiar territory from years earlier. Yet every option came with a recurring subscription, monthly fees, or a feeling that I was renting somebody else's platform.

This wasn't going to be a large commercial operation. I was producing small seasonal batches of local honey. The idea of paying ongoing software costs before selling a single jar felt backwards.

If the business succeeded, I wanted to own it end-to-end. If it failed, I wanted to learn something. Either way, building it myself seemed like the more interesting option.

The New World

At the time, AWS had something relatively new that had caught my attention: Amplify.

My background was still heavily influenced by PHP, WordPress and traditional LAMP stack thinking. React had been around for years. And i was beginning to feel like a dinosor, having never tried it. I quickly found NextJS as my entry point. Amplify promised a modern development experience where a frontend project could be deployed directly into AWS with backend services integrated along the way.

It felt exciting. It felt like the future. So down the rabbit hole I went.

Version One

The first version was intentionally simple. Products existed, they could be displayed on a homepage, Stripe could accept payments, and the site looked professional. That last part mattered to me. Features are important, but good user experience comes first. If users can't make sense of a website, the features almost don't matter.

After evaluating a number of design libraries I settled on Mantine. It gave me a consistent design language and a collection of components that let me focus on solving problems rather than drawing buttons. Looking back now, version one was almost charmingly simple.

Unfortunately, simple projects rarely stay simple.

The Ground Shifted Beneath Me

Not long after I started, Amplify itself changed.

AWS introduced Amplify Gen 2. Migration wasn't mandatory. Gen 1 would continue to work. Many people understandably chose to wait.

I looked at it differently.

If I was eventually going to refactor, why not do it while the project was still relatively young?

So I migrated.

In hindsight, that decision accelerated my learning dramatically.

The challenge was that Gen 2 was still early. Documentation was improving rapidly but many examples were incomplete, community discussions were limited, and sometimes the answer simply didn't exist yet. There were moments where it felt like I was wandering through the wilderness with a compass and a vague idea of where I wanted to go.

That turned out to be one of the most valuable parts of the project.

Instead of following tutorials, I had to understand how things actually worked.

Along the way I found a handful of issues and edge cases that I raised with the Amplify team. Some related to storage permissions, others to interactions between authentication groups and resource access.

For the first time I wasn't simply consuming a platform.

I was participating in it.

A Profile Picture Changes Everything

Like many engineering stories, things started to become complicated because of a feature that sounded completely reasonable.

What if users could upload a profile picture?

It sounds like a simple feature. Most websites support it. It feels almost expected.

So I built it.

Then I wanted administrators to see those profile pictures. Then I wanted them to load quickly. Then I wanted them cached correctly.

That led me into signed URLs. Which led me into expiry windows. Which led me into browser caching. Which led me into CloudFront.

Up until this point, Amplify still felt a little bit magical.

Then I opened backend.ts.

That file became the doorway.

Up until then I was consuming Amplify features. From that point onwards I was extending them. Attaching IAM policies. Creating permissions. Connecting resources. Thinking about infrastructure.

Somewhere along the way I realised Amplify wasn't hiding AWS from me. It was introducing me to it.

Underneath the abstractions sat CDK constructs. Underneath CDK sat CloudFormation. The further I pushed, the more of the underlying machinery became visible.

The surprising part was that this wasn't fighting Amplify.

This was exactly how it was designed to be extended.

Seeing the Matrix

Somewhere along the way, AWS stopped feeling like a collection of separate services.

Before OnliHoney, Cognito was Cognito. SES was SES. DynamoDB was DynamoDB. CloudFormation was something I occasionally saw in documentation examples.

During OnliHoney, those services started to become building blocks.

DynamoDB stored products and orders. AppSync exposed application data. Cognito handled identity. CloudFront delivered content globally. SES sent notifications. Lambda allowed custom business logic.

More importantly, I started to understand the layers connecting them.

Amplify generated CDK. CDK generated CloudFormation. CloudFormation created resources.

I stopped seeing services.

I started seeing systems.

By this point the architecture had evolved far beyond a simple online store. What started as products and payments had grown into a collection of services handling identity, content delivery, notifications, data, administration and integrations.

The funny thing is that none of this was planned on day one. It emerged gradually as each new requirement nudged the system in a slightly different direction.

Things Nobody Puts in Tutorials

The hardest problems weren't always the ones I expected.

Stripe integration consumed far more time than the checkout page itself. Managing product synchronisation without double entry became an obsession. If a product was created or deleted, I wanted Stripe to know about it. Duplicate administration annoys me more than almost anything. It leads to human error.

Another challenge was combining Cloudscape and Mantine in the same application. Both are excellent. Both have very different opinions about styling.

Making them coexist while supporting light and dark themes became one of those jobs that sounds like an afternoon and quietly consumes a weekend.

Then there were build times. Early Amplify deployments felt magical. As the project grew, deployments stretched into twenty minute builds. Failed builds still cost money. More importantly, they cost momentum.

It forced me to become more deliberate about local testing and more careful about what I deployed.

Goodbye CodeCommit

The project originally lived in AWS CodeCommit.

When AWS announced the service was being sunset, I reluctantly migrated to GitHub. I wasn't enthusiastic about the move. I have a desire to keep everything within AWS, but I also value the community and tooling.

With GitHub I joined a larger community and I overcame the biggest barrier, my fear of what I thought would be a heavy lift. Turns out git repos are a few clicks to move.

By the time AWS changed course and decided CodeCommit would remain available, I had already settled into GitHub workflows and decided to stay.

Sometimes platform changes force you into decisions you wouldn't otherwise make. Occasionally those decisions work out for the better.

What OnliHoney Really Taught Me

Looking back, I wouldn't change a thing.

OnliHoney taught me how all of these pieces connect together. More importantly, it taught me that architecture isn't about finding the perfect design. It's about finding the right design for the problem in front of you.

Amplify got me started. CDK showed me how things fit together. CloudFormation showed me what was really happening underneath.

Not every application needs infinite scale. Not every solution needs microservices. Not every architecture diagram deserves a conference talk.

Build what works. Understand how it works. Improve it when necessary.

Ideas turn into production surprisingly quickly when you own the whole stack.

AWS also changed how I think about vendor lock-in. Ironically, I often feel less constrained here than I would on many managed platforms. If I need a service, I can turn it on. If I need an API, I can call it. If I need a different architecture tomorrow, I can build it.

The real lesson wasn't about honey. It wasn't even about eCommerce.

It was about confidence.

The confidence that comes from looking at a working system and saying:

I built this.

Not because a tutorial told me to.

Not because a platform generated it.

But because I followed an idea, solved problems as they appeared, and kept going until it worked.

I set out to build a website for selling honey.

Instead I learned React, NextJS, Amplify, CDK, CloudFormation, DynamoDB, AppSync, Cognito, CloudFront, SES and a dozen lessons about software architecture.

The honey was real.

The website was real.

But the most valuable thing I built was confidence.