Building Became Easy. Finding the Right Problem Did Not.

Building for a problem I was living myself

Around 2024, I started thinking seriously about turning those problems into a product.

Unlike many software projects I had worked on before, nobody gave me requirements.

I was one of the users.

That was useful, but also dangerous. It meant I had strong intuition about the problem, but it also meant I could easily assume that what frustrated me frustrated everyone else.

So I started with the problems I could actually see in my own garden.

None of them lived in isolation. It was unclear who belonged to the garden. Parcels were hard to track. Events were organized through messages that quickly became noisy. The association had money to manage and decisions to make as a group. And underneath all of that was a harder question: how do you keep a community garden functioning as a shared project, not just a collection of individual plots?

Over time, that mess of practical questions became the outline of the product.

But my garden was only a starting point. I also started talking to other gardeners, still informally, to see whether the same problems appeared elsewhere.

At first, the question was personal:

This is annoying in my garden.

Slowly, it became something broader:

Is this a recurring problem for community gardens?

Then life interrupted the product

I started designing CoGarden, exploring the flows and thinking about what the platform should become.

Then I stopped.

I had a child, and the product understandably moved down the list of priorities.

For a while, CoGarden remained an unfinished idea.

That pause became interesting in retrospect because when I came back to it, the way software could be built had changed dramatically.

In November 2025, while I was on holiday, I decided to restart the project.

This time, I used AI heavily, particularly Cursor.

What happened next surprised me.

In roughly eight days, most of the main functionality existed.

Not prototypes.

Not just screens.

The major features of the application were there, live at cogarden.app.

When implementation stopped being the bottleneck

AI changed the economics of the project almost immediately.

Before, building an application of this scope alone would have required a significant amount of time.

Now I could describe what I wanted, inspect the result, test it, correct it and keep moving.

Implementation became dramatically faster.

But that speed created a new problem.

I could no longer realistically read every line of code being produced.

My role started changing.

Instead of personally writing and understanding every implementation detail, I increasingly focused on whether the feature behaved correctly.

Does the workflow work?

Does the UI make sense?

Does this action produce the right result?

Can the user complete what they are trying to do?

What is the role of a software engineer when software can be produced faster than the engineer can read it?

Speed without a safety net

One of my mistakes was testing.

Or, more precisely, the lack of automated tests.

I had moved very quickly with AI, and I had not explicitly made automated testing part of the development process.

The application grew.

Features worked.

I tested them manually and moved on.

But without a strong automated test suite, every new change increased the uncertainty around what had already been built.

Later, I discovered that features that had worked correctly at one point had stopped working after subsequent changes.

That was a useful correction to the excitement around AI-generated development.

AI had made it possible to create functionality extremely quickly.

It had also made it possible to create regression risk extremely quickly.

The problem was not necessarily that the code had been generated by AI.

The problem was that the engineering system around that code had not evolved at the same speed.

If code becomes cheaper to produce, confidence in that code becomes more important, not less.

At Kappa Engineering, small changes combined with strong automated testing created speed with controlled risk.

With CoGarden, rapid implementation without equivalent test discipline exposed the opposite problem.

Can production software exist without reading every line?

Before CoGarden, I had doubts about whether it was realistic to produce real software with AI without personally reading all the generated code.

The experience changed my position.

It showed me that, at least for a product like CoGarden, it was possible to create and deploy something functional while operating at a higher level than line-by-line implementation.

But it also made responsibility more demanding elsewhere.

If I am not reading every line, then I need stronger ways to establish confidence.

Testing becomes more important.

Monitoring becomes more important.

Architecture becomes more important.

Security becomes more important.

Understanding the expected behavior of the system becomes more important.

Production arrived before the customers

Then CoGarden taught me another lesson in an unexpected way.

I deployed the application.

There were almost no users.

But the internet did not care.

Bots found it.

The application started receiving automated attacks even though there was almost nobody using the product.

I ended up spending a surprising amount of time configuring Cloudflare and improving the way the application was protected.

The contrast was almost absurd.

I had used AI to implement major parts of the product in a matter of days.

Then I spent more time dealing with automated traffic and infrastructure protection than I had spent implementing some significant features.

You do not need customers before you have production problems.

The hardest problem was waiting outside the codebase

Once CoGarden existed, I arrived at the part that had already challenged me with MyEasyTransfer:

getting people to use it.

I contacted community-garden associations by email.

Very few answered.

Some initially responded, but when I tried to arrange a meeting, the conversation stopped.

At the same time, I did not have enough time to consistently work on marketing, outreach and customer acquisition.

So CoGarden reached an uncomfortable position.

The software existed.

The main features existed.

The application was deployed.

But there were no paying customers.

Today, my own garden has access to it as a free user.

That is very different from having a validated business.

Is this actually a problem worth solving?

Lack of customers is not yet an answer

It would be easy to conclude:

Nobody is buying it, therefore nobody needs it.

But I do not think I have enough evidence to make that conclusion yet.

There are several possible explanations.

Maybe the problem is not painful enough.

Maybe community gardens already have solutions that are good enough.

Maybe people need CoGarden but do not know it exists.

Maybe email outreach is the wrong acquisition channel.

Maybe associations need more trust before adopting a tool that changes how they work.

Maybe the current price is too high.

Or maybe people would use it but would never pay enough for it to become a viable business.

These hypotheses are currently mixed together.

My next experiment may be to remove one variable completely:

price.

I am considering offering CoGarden to some gardens for free and watching what happens.

Not because I necessarily want the product to remain free.

But because I want to answer a more fundamental question first:

If price disappears, will people actually adopt the product?

Testing adoption before testing the business

If community gardens start using CoGarden regularly when it is free, that would give me evidence that the underlying problem exists.

Then I can separate another question:

Do they value it enough to pay for it?

But if gardens sign up and then stop using it, that tells me something different.

And if I cannot convince people even to try it for free, then I need to question more deeply whether I am solving the right problem, targeting the right people, or communicating the value correctly.

For now, the metric I care about most is not revenue.

ADOPTION

Do real gardens use it?

Do members come back?

Does it become part of the way the association operates?

Would people notice if it disappeared?

Only after answering those questions does pricing become particularly interesting.

CoGarden is therefore still an experiment.

The product has been built.

The hypothesis has not been proven.

AI did not remove the difficult questions

CoGarden confirmed something I had already started learning through MyEasyTransfer:

Marketing and selling can be much harder than implementation.

AI has made that difference even more visible.

Knowing when to stop is also part of building

This may be the hardest part of CoGarden for me personally.

I do not want to abandon a potentially useful product simply because my first attempt at selling it did not work.

At the same time, persistence alone does not make an idea good.

There is a danger on both sides.

Stop too early, and I may abandon something just before discovering how to make it work.

Continue indefinitely, and I may spend years protecting an idea from evidence that nobody really wants it.

I do not have the answer yet.

I know I can build CoGarden. I still don't know whether CoGarden should become a business.

Learning how to answer that question may ultimately be more valuable than building the application itself.