Building Promobet, One Layer at a Time

So, I'm back.

After dedicating some of my free time to other projects, I've started spending more of it on Promobet again. And one of the first things that struck me when I came back was something I wasn't entirely expecting:

The architecture actually held up.

It's a surprisingly satisfying feeling.

When you're deep inside a project, you're constantly making decisions that feel temporary. You create an abstraction because you need it today. You separate a service because something is getting too complicated. You introduce a context, a pipeline, a validator, an adapter, or another layer because the current problem demands it.

At the time, it's easy to wonder whether you're overengineering things.

Then you leave the project for a while, come back, and realize you can still understand why everything is where it is.

That happened with Promobet.

And because I own the codebase and have been involved in most of the decisions behind it, the project is considerably more comprehensible to me than something I would inherit from someone else.

That might sound obvious, but I think it's an important part of software development that doesn't get discussed enough.

Architecture isn't only about making software work. It's also about making the software understandable to the people who will have to keep working on it.

And now that Promobet is reaching a more mature stage, that distinction is becoming increasingly valuable.

When Documentation Starts Making Sense

One of the things I'm beginning to consider seriously is documentation.

Not documentation for the sake of documentation, but documentation that follows the actual structure of the application.

The project now has enough distinct modules and flows that documenting the different client-side and server-side responsibilities starts to feel like a reliable investment.

The separation of concerns we enforced throughout development should make that considerably easier.

There are ingestion layers.

Adapters.

Enrichers.

Transformers.

Validators.

Verification.

Catalog management.

Tenant-level resources.

User-level resources.

Analytics.

Seasonal statistics.

And the frontend has its own corresponding structures for managing selection, catalog state, tenant configuration, and the different interactions that happen around those systems.

The interesting part is that these aren't isolated abstractions anymore.

They're becoming a system.

And that's probably the point where documentation starts becoming useful: when the architecture has enough shape that someone can understand the flow without having to read the entire codebase.

From Importing Products to Maintaining a Catalog

One of the areas I've been working on recently is the Tenant Catalog interface.

This is where several of the systems we've previously built start coming together.

A tenant can import products, but importing something isn't enough.

The platform needs to know whether that product is actually reachable and usable.

That led us toward a more structured ingestion and verification pipeline.

The idea is relatively simple:

Don't let the catalog become a graveyard of products that no longer work.

Affiliate providers change URLs. Products disappear. Offers expire. Pages become unreachable. Data becomes stale.

If a tenant is relying on the platform's catalog, then the platform should provide more value than simply storing whatever was uploaded.

It should provide a layer of verification.

That means the ingestion system doesn't just answer:

"Can I parse this product?"

It increasingly needs to answer:

"Should this product remain part of the catalog?"

That's an important distinction.

The ingestion pipeline we've been developing separates concerns around adapting incoming data, enriching it, transforming it into our internal representation, validating it, and eventually verifying the resulting product.

This also gives us a much better place to introduce additional functionality later.

For example, I'm considering introducing a kind of catalog freshness warning.

Instead of requiring a tenant to re-upload their entire catalog just to discover whether existing products are still reachable, the platform could track when an item was last verified and surface a warning when that information becomes stale.

That could be particularly useful for tenants relying on affiliate providers.

At the same time, users with proprietary links may not need that warning. If they own the products and control the destination themselves, they should be able to disable that particular concern.

But the verification pipeline itself should remain available for registered products.

That gives us a fairly flexible model without making the system unnecessarily complicated.

The Architecture Is Also the Business Model

This is where the project gets more interesting to me.

Promobet isn't being designed around taking a percentage of every sale.

The intention is to generate revenue through subscriptions.

That changes some of the architectural and product decisions.

If the platform's revenue depends on tenants paying for access, then the value proposition has to exist independently of whether the platform takes a cut from every transaction.

The platform needs to provide something worth paying for.

That means the catalog, verification, analytics, seasonal systems, resource management, and the overall experience aren't just technical features.

They're part of the product's argument for existing.

There is also a more difficult question here:

What happens if the tenants don't aggregate enough users?

Even with subscription payments, a platform like this needs tenants who actually have an audience.

That's why the initial target audience isn't necessarily someone starting from zero.

The more interesting users are people who already aggregate audiences through fan bases, communities, portals, influencers, or other established channels.

The tenant brings the audience.

The platform provides the experience.

And the users interact with the products.

That relationship is what I'm trying to build around.

A Different Kind of Game

This is probably the strangest part of the project.

Promobet intentionally borrows some of the language and interaction patterns associated with casino experiences.

Spinning.

Anticipation.

Visual feedback.

Rewards.

Scarcity.

Progress.

Randomized discovery.

But the underlying intention is different.

I've spent quite a bit of time thinking about that contradiction.

Can you use the interface language of a casino without actually building a casino?

More importantly:

Can you take some of the psychological triggers that make those experiences engaging and redirect them toward something less extractive?

The philosophy behind Promobet is that the tenant should not simply "win" because the user loses.

The tenant provides products.

The platform provides the infrastructure and experience.

Users discover products they may actually want.

If the tenant offers good products and has an engaged audience, everyone can benefit.

The platform benefits from the subscription.

The tenant benefits from engagement and sales.

The audience gets an experience built around discovering something they might actually want.

It's intentionally closer to an anti-casino model.

The house doesn't always have to win.

That doesn't mean the mechanics themselves are inherently good or bad. It means I'm interested in what happens when you take those mechanics out of their traditional environment and give them a different purpose.

Of course, that's an aspiration.

Nothing about building a product guarantees that the philosophy survives contact with reality.

But I think it's worth exploring.

The Small Things Still Matter

The architecture may be holding up, but the product isn't finished.

There are still plenty of small UX interactions that need attention.

Some are obvious.

Others are the tiny things that only become visible when you actually use the system repeatedly.

What happens when an import takes longer than expected?

What does the interface communicate while a verification is running?

What should happen when a product becomes unreachable?

What does the tenant see when a resource changes state?

How should the platform communicate limitations without making the interface feel restrictive?

These aren't necessarily big engineering problems.

But they are the kinds of problems that determine whether a system feels coherent.

Fortunately, the component architecture is already giving us places where these behaviors can live without having to restructure the entire application.

That's another thing I appreciate about coming back to the project.

The foundations give us somewhere to put the next problems.

There Is Still a Lot Left

There are several gaps that still need to be filled.

The extended user options are one.

Users should eventually be able to delete their accounts, while subscription rules need to be respected. If someone has an active subscription, cancellation needs to happen before account deletion.

There also needs to be a proper reporting flow for bugs and inappropriate content.

And, of course, Stripe still needs to be integrated into the tenant and user models so subscriptions can actually be created, managed, and cancelled.

I'm currently finishing the Tenant Catalog interface while connecting it to the ingestion systems we've already tested and adding the verification layer.

There's still plenty of work ahead.

But the nice thing is that the work is becoming increasingly compositional.

We're not reinventing the entire system every time we add something.

We're connecting pieces that already have defined responsibilities.

And that's probably the biggest sign to me that the architecture is moving in the right direction.

The Risk of the Model

There is also a business risk that I can't ignore.

If the model depends on recurring subscriptions from tenants, but those tenants don't bring enough users into the experience, the economics don't work.

It's possible to build a technically beautiful platform that nobody needs.

That's one of the uncomfortable realities of software development.

The architecture can be correct.

The implementation can be clean.

The product can be interesting.

And it can still fail.

That's why the audience strategy matters.

The goal isn't simply to find people who might enjoy the product.

It's to find people who already have communities capable of making the experience meaningful.

Influencers, fan communities, portals, niche audiences, and people who already aggregate users are therefore much more interesting potential tenants than someone who has no audience at all.

We've also introduced caps around the platform's resources so that usage can scale with the subscription model rather than creating an unlimited cost center.

In the end, it's a bet.

A technical bet.

A business bet.

And, to some extent, a philosophical one.

Maybe It Works. Maybe It Doesn't.

This is probably where the project stops being purely technical for me.

I don't know if Promobet is going to work.

Maybe it will.

Maybe it won't.

Maybe I'll finish it and discover that the market doesn't want it.

Maybe I'll learn enough from building it that it leads me toward a completely different opportunity.

Maybe I won't even finish it.

It could eventually become nothing more than a small piece of evidence that, at one point in my life, I was motivated enough to throw myself into a difficult problem without knowing what would come out of it.

And that's okay.

There is no easy path through any of this.

I once heard something that stayed with me:

The only way to know you're on the right path is when the path ahead disappears in front of you.

I didn't understand that the first time I heard it.

I think I do now.

How could there be a path ahead if you're carving your own?

Sometimes you don't know whether you're going in the right direction because there isn't anything there yet.

You're building the direction as you move.

So if you're feeling lost because you don't have a clear path ahead of you, maybe that's not necessarily evidence that you're going the wrong way.

Maybe it just means you're making your own.

And Then There Is AI

Coming back to Promobet has also made me think about the current state of software development.

Especially the current obsession with agents.

Agentic coding.

AI-powered development environments.

Frameworks for building agents that build other things.

Systems that generate systems.

And I keep coming back to one question:

Is everything we can build something that should be built?

We already have incredibly capable LLMs that can help us write code, reason about architecture, review implementations, explore alternatives, debug problems, and reflect on engineering decisions.

That is already an enormous change to the way software can be developed.

But now we're seeing an enormous influx of products and abstractions built around that capability.

Sometimes it feels like we're building increasingly elaborate structures whose primary purpose is to build more structures.

And then those structures build more structures.

At some point, I can't help but think of an ouroboros.

A snake eating its own tail.

There is nothing inherently wrong with building new tools. In fact, many of them are genuinely useful.

But I wonder where the boundary is between increasing our ability to create and simply increasing the amount of things being created.

More software doesn't automatically mean more value.

More automation doesn't automatically mean more progress.

More products don't automatically mean a better ecosystem.

And if the ability to produce software keeps accelerating, the bottleneck may eventually stop being:

"Can we build this?"

and become:

"Should we build this?"

That's a much harder question.

Back to the Lab

For now, I'm not particularly interested in having an answer to all of that.

I'm interested in continuing to build.

Promobet is still unfinished.

There are still systems to connect, interfaces to refine, subscriptions to integrate, verification flows to improve, documentation to write, and a business model to test against reality.

But coming back to the project and seeing that the decisions made months ago still make sense has been genuinely satisfying.

It makes the next stage feel less like starting over and more like continuing a conversation with something I already built.

And maybe that's one of the best outcomes architecture can give you.

Not just software that works.

Software that you can come back to.

Understand.

Question.

Change.

And keep building.

So, yes.

There's a lot left to do.

Back to the lab.