Building a Complex Site with a Backend - Emergent

When I started with Foodopia, the idea was still significantly simpler than what it has become today.

I wanted to build a platform where small producers, hobby gardeners, or people who make food at home could offer their products directly in their local area.

The idea behind it was actually quite simple: there are many people who produce eggs, fruit, vegetables, honey, or other foodstuffs and sometimes have more than they need themselves. At the same time, often only a few kilometers away, there are people who would love to buy such products locally but don't even know they exist.

I wanted to bring exactly these two sides together with Foodopia.

A large part of the platform was created with Emergent.

Why I Used Emergent for Foodopia

I come from software development myself and have worked for several years in a traditional way on Java backends, APIs, cloud systems, and larger enterprise projects.

Normally, with a new project, I would relatively quickly start thinking about data models, backend structure, APIs, frontend components, and deployment.

With Foodopia, things were a little different.

Initially, I could simply explain to Emergent what I actually wanted to build.

For example:

A producer should be able to list a product, select one or more pickup locations, and define time slots during which customers can pick up their order.

From this description, a functioning implementation could be created relatively quickly.

What was interesting for me was less that I didn't have to write any code. Much more important was that I could quickly test whether my idea made sense at all.

A Small Idea Quickly Grew into a Larger System

As with many software projects, the actual requirements only emerged during development.

A producer doesn't just need a product form.

They need a profile, available quantities, prices, VAT rates, pickup locations, and pickup times.

Then came the question of whether reservations should be automatically confirmed or if the producer wanted to confirm each reservation themselves.

After that, the Pickup Locations were developed. The idea here is that, for example, a shop can serve as a pickup point for multiple producers and receive a small fee for it.

Later, payments via Stripe Connect were added.

This made the whole thing significantly more complex, because suddenly not just UI and database were relevant, but also payment flows, platform fees, producer accounts, webhooks, and payouts.

Especially with such topics, you quickly realize that AI development doesn't simply mean:

"Write me a platform."

The more systems are connected to each other, the more important it becomes to understand what is happening in the background.

The Business Model Changed During Development

Foodopia didn't look exactly the same at the beginning as it does today.

An earlier idea was to work more with our own hubs and logistics.

The more I looked into it, the less sense it made for Foodopia itself to become a logistics company.

Today, the idea is much clearer:

Foodopia provides the platform.

Producers decide for themselves where and when their products can be picked up. They can use their own location or collaborate with Pickup Locations.

This change wasn't just a business decision. It naturally also had an impact on the software.

With Emergent, I could implement such changes relatively quickly and try out different variations.

For me, that's one of the biggest advantages of this type of development.

Especially with a new product, you just don't know everything at the beginning.

Many things you only understand once you've actually built them.

Foodopia Was Never Meant to Be Just a Marketplace

One part of Foodopia that was important to me from the very beginning is the community.

I find it a shame that food has often become completely anonymous today.

You buy tomatoes, eggs, or honey without knowing who is behind them or how they were produced.

That's why Foodopia also has a social section.

Producers can, for example, show what's currently happening in their garden or on their farm, share pictures of their harvest, create events, or form groups.

This doesn't always have to be advertising.

A picture of newly hatched chicks, a fig tree, or the first tomato harvest can be just as interesting.

I want people to regain a bit more connection to where their food actually comes from.

Where Emergent Works Very Well

What I particularly like is the speed.

I can describe an idea and relatively quickly see how it feels within the platform.

If something doesn't fit, I change it.

If a function has become unnecessarily complicated, I can simplify it again.

If a better solution occurs to me during testing, I don't have to plan several days of development first.

The development process has thus become much more iterative.

It often goes something like this:

Idea → Prompt → Implementation → Testing → Find errors → Adjust

Sometimes I work with text descriptions, sometimes with screenshots.

Especially with UI issues, it's very practical to simply show a screenshot and explain exactly what bothers me about it.

Still, You Have to Know What You're Doing

I don't believe that tools like Emergent make technical knowledge superfluous.

Quite the opposite, in fact.

If AI can generate software very quickly, someone needs to be able to assess whether the result is sensible.

For Foodopia, this concerns, for example:

• Stripe and payment flows
• Authentication and permissions
• Database changes
• Webhooks
• SEO
• Sitemap and Google Search Console
• VAT
• Invoicing processes
• Data privacy
• different requirements in various EU countries

With simple UI adjustments, you can experiment relatively freely.

However, with payment logic or security-relevant functions, I want to understand exactly what is happening.

AI can build something very quickly.

But that doesn't automatically mean the solution is correct.

My Role as a Developer is Changing

This is probably the most interesting part for me.

Previously, a large part of my work consisted of translating requirements into code myself.

Today, with projects like Foodopia, I spend much more time defining the right requirements.

I think more about:

• How should a process actually work?
• What does the user really need?
• What are the edge cases?
• Which function can be made simpler?
• What impact does a change have on other parts of the platform?

The focus shifts somewhat from merely writing code to architecture, product thinking, testing, and review.

This doesn't mean that programming becomes unimportant.

But the way software is created is changing.

What Has the Development Cost Me So Far?

One point that often gets overlooked in AI development is the ongoing costs.

Emergent works with a credit system. Depending on which package you buy, the effective price per credit changes slightly.

At the time of my use, the prices were approximately:

Credits	Price
100	$20
250	$50
500	$100
1.250	$250
3.000	$500
6.000	$1.000

I mostly bought the 1,250-credit package for $250. Occasionally, there were also smaller packages for $50 and, at times, the 3,000-credit package for $500.

For the development of Foodopia, a total of approximately 8,066.53 credits have been used so far.

If you calculate these credits with the standard packages at about $0.20 per credit, this corresponds to approximately:

8,066.53 × $0.20 = $1,613.31

Since the larger packages are slightly cheaper, the actual effective amount is somewhat lower depending on the combination purchased. Realistically, the development consumption so far corresponds to approximately $1,350 to $1,600.

However, this is not exactly the same as my total deposits, as purchased credits may, of course, still be remaining in the account.

Ongoing Backend Costs

In addition to the actual development, there are ongoing costs for hosting and the backend.

Currently, the Foodopia backend costs me:

50 credits per month

At the standard credit price, this equates to approximately $10 per month.

For me, this is an interesting comparison to traditional software development. Around $1,500 is certainly money, but at the same time, it has resulted in a platform with a marketplace, producer management, reservations, payments, community features, and various external integrations.

Had I commissioned these functions to be developed entirely externally, the costs would very likely have ended up in a completely different magnitude.

Nevertheless, AI development should not be seen as "free software development." Especially if you experiment a lot, develop new functions, or revise existing solutions multiple times, credits can be used up quite quickly.

The great advantage for me is therefore less that development suddenly becomes free, but rather that for comparatively little money, I can experiment, test, and build a real platform very quickly.

Foodopia is Far From Finished

Foodopia is still a young project.

There are many things that will likely still change.

Especially as more producers start using the platform, requirements will likely emerge that I'm not even thinking about today.

And that's precisely why this type of development suits the project very well.

I can take feedback, try out new ideas, and modify functions without turning each instance into a huge development cycle.

Foodopia was launched in Portugal, but in the long term, the platform is intended to function in other European countries as well.

For this, several technical and legal issues still need to be resolved.

But the core of the idea remains very simple:

Local food should be easier to find.

And food that has already been produced should ideally not be thrown away just because nobody knows it's available.

With Emergent, I was able to relatively quickly turn this idea into a real platform.

Now, the more exciting part begins for me: finding out how people actually use Foodopia.

👉 https://foodopia.eu