I really enjoy building projects.
I've always had ideas, probably more than I can realistically build. I'm usually excited about the next concept, eager to start coding, and curious to see something come to life. For a long time, my pattern was simple: get an idea, build it, then move on to the next one.
At first, that felt productive. But over time, I started to notice a problem.
I was building a lot and finishing very little that actually mattered.
From ideas to impact
Building a successful project isn't just about having ideas or shipping fast. It's about getting your first users, understanding what people really need, and learning what the market actually wants, not just what you think is interesting.
That shift in thinking took time.
I began to realise that moving from idea to idea was easy. The harder part was sticking with one thing long enough to understand users, collect feedback, and improve it intentionally. Without that, even good ideas struggle to go anywhere.
Building is easier than ever, success isn't
One of the biggest changes in recent years is how accessible building has become.
With modern tools, cloud platforms, and AI-powered development tools, you can take an idea and turn it into an MVP incredibly fast. What used to take months can now take days.
And that's a great thing.
But I've learned, through experience, that speed alone doesn't equal success.
I've built apps and websites in the past that worked perfectly from a technical point of view. They were functional, polished, and ready to use. The problem was simple: no one used them.
Not because they were bad, but because no one knew they existed.
The real challenge is distribution
That's where the real lesson clicked.
The hard part isn't always building the product. The hard part is distribution, getting people to see what you're building, care about it, and engage with it. It's about communication, visibility, and trust.
And importantly, distribution doesn't start after you launch.
It starts while you're building.
Why I decided to build in public
For a long time, I built quietly. I worked on projects behind the scenes, launched them silently, and hoped users would somehow discover them.
They didn't.
So I decided to change my approach.
Building in public is my way of being more intentional, sharing what I'm working on as I build it, talking about ideas early, documenting progress, and learning from feedback instead of building in isolation.
It's not about pretending to have everything figured out. It's about being honest about the process and allowing people to follow along if they find it useful.
What building in public looks like for me
For me, building in public means:
- Sharing what I'm building and why
- Talking openly about what's working and what isn't
- Documenting lessons, mistakes, and small wins
- Staying consistent instead of waiting for perfection
Some projects will work. Some won't. That's part of the process. The goal is to learn faster, build better, and create things that actually reach people.
What BuildWithKenny is
BuildWithKenny is my public workspace.
It's where I document the behind-the-scenes of building, the ideas, the experiments, the decisions, and the lessons that don't usually make it into polished case studies.
Think of it as an open notebook rather than a highlight reel.
Moving forward
I still love ideas. I still love building.
The difference now is that I want to build things that don't just exist, but actually get used. I want to understand users earlier, improve faster, and stay accountable to the work.
That's why I'm building in public.
This is just the beginning.