Coder Legion - Recent posts tagged product

Multi-tenant SaaS, explained with a football academy

Sat, 31 Oct 2026 12:30:00 +0000

"Multi-tenant" is one of those words that sounds harder than it is.
I put it on my CV.
Track My Academy is multi-tenant and role-based.
Real academies run on it.

So here's what that actually means, for beginners.
No cloud diagrams.
Just a football academy, a building, and some locked doors.

One note before we start.
This is about the general idea and the textbook patterns.
It is not a tour of how Track My Academy is wired inside.

Photo: Leo_Visions on Unsplash

The building: what a tenant is

Picture one big sports building.
Lots of academies rent space in it.
Each one has its own players, coaches, fees and attendance.

Every academy is a tenant.
The building is your software.

Microsoft's guide to tenancy models says that if your customers are other organisations, you usually map each tenant to one customer.
It also says a single tenant typically has many users.
One academy, many people.

That's the whole trick of SaaS.
You build the building once.
Everyone rents.

The rooms: roles

Inside one academy, not everyone gets the same keys.

The owner sees everything: fees, invoices, every batch.
A coach sees their batches and marks attendance.
A parent sees their own child, their invoices, their messages.
A player sees their own reports.

That is role-based access control, or RBAC.
NIST, who formalised the model back in 1992, says it has become the predominant model for advanced access control because it reduces the cost of managing access.
Users get roles. Roles get permissions.
You don't hand out keys one person at a time.
You hand out "coach keys".

The model was later adopted as a standard, ANSI/INCITS 359, first in 2004.
Not a new idea. Just a very useful one.

Here's the bit people mix up.
Roles decide which rooms you can enter inside your academy.
Tenancy decides which academy's rooms you can see at all.
A coach at Academy A should never see Academy B's attendance, even with full coach keys.
Microsoft's guide puts it as needing to consider both tenant and user identity when you authorise anything.

AWS's SaaS Lens names three patterns: silo, pool and bridge.

Silo. Every academy gets its own building.
In software terms, dedicated resources per tenant: its own stack, or at least its own database.
AWS notes that even a silo still shares one identity, onboarding and operations setup.
Otherwise you're running a managed service, not SaaS.

Pool. Everyone shares one building.
Same servers, same database, same tables.
AWS calls it "the more classic notion of multi-tenancy".

Bridge. A mix.
Some parts siloed, some pooled.
AWS says this acknowledges that "SaaS businesses aren't always exclusively silo or pool."

Microsoft describes the same spectrum, from fully isolated to fully shared, and says to treat isolation as a spectrum, not a switch.

Photo: Steve Pancrate on Unsplash

Same surface, separate lanes. That's roughly the picture.
In the database, it usually looks like one of these:

Model	Academy analogy	Trade-off
Database per tenant	Each academy has its own building	Strong isolation, costs grow with every new tenant
Schema or collection per tenant	Own floor, shared building	In between, and more things to manage
Shared tables with a `tenant_id`	Shared rooms, every item labelled with the academy's name	Cheapest, but every query must filter correctly

MongoDB's own multi-tenant guidance is blunt about the middle option.
It says to "avoid putting all tenants with their own collections into a single database."
It suggests a database per tenant for a small, stable number of tenants with strict access needs.
And shared collections when tenant numbers keep growing.

With shared collections, MongoDB says: "Every document must have a tenantId field, and every database query must filter by that field."
That sentence is the whole risk of the pool model.

The noisy neighbour

Shared buildings have one classic problem.
One academy throws a party and the whole building shakes.

Microsoft calls it the noisy neighbour antipattern.
It happens "when one tenant's performance is degraded because of the activities of another tenant."
Say one academy runs a giant report while another is marking attendance at the gate.
The second one waits.

The fixes on that page are sensible.
Monitor usage per tenant, not just overall.
Apply quotas, throttling or rate limits.
Run heavy, non-urgent jobs at off-peak times.
Cap expensive queries.

The silo model mostly avoids this.
Microsoft's tenancy guide says dedicated deployments make tenants unlikely to affect each other's performance.
But if one tenant costs X, it says, 100 tenants probably cost 100 times that.

The scary one: data leaks

Noisy neighbours are annoying.
Leaks are a different category.

AWS's whitepaper on tenant isolation strategies says crossing that boundary "would represent a significant and potentially un-recoverable event for a SaaS business."
Imagine a parent opening the app and seeing another academy's fee list.
That's not a bug report. That's a trust problem.

In a shared database, one forgotten filter is enough.
So I think the safest habit is to not rely on remembering.
Make the database refuse.

PostgreSQL has row-level security for exactly this.
Once it's on and no policy exists, it uses default-deny: no rows are visible or can be modified.
Supabase's RLS guide builds on the same feature and points out it still protects data when it's reached through third-party tools.

Here's a small illustrative example.
It is not Track My Academy's code, just the pattern:

-- Example only: a shared attendance table, labelled by academy.
ALTER TABLE attendance ENABLE ROW LEVEL SECURITY;

CREATE POLICY academy_isolation ON attendance
  USING (academy_id = current_setting('app.current_academy')::uuid);

The app sets app.current_academy for each request.
Postgres then filters every query on that table to that academy, even one where someone forgot the WHERE.

Two catches from the Postgres docs.
Superusers and roles with BYPASSRLS always skip these policies.
Table owners do too, unless you use FORCE ROW LEVEL SECURITY.
So the app shouldn't connect as the owner.

How I'd think about it

My opinion, for a small team:

Decide what a tenant is on day one. For academy software it's obvious. For other products it often isn't.
Put the tenant ID on everything. Retrofitting it later is miserable.
Let the database enforce isolation where it can. Code reviews miss things. Default-deny doesn't get tired.
Keep roles and tenancy separate in your head. Different questions, different checks.
Watch per-tenant usage. You can't fix a noisy neighbour you can't see.
Test for leaks on purpose. Microsoft's guide says to verify one tenant's data isn't leaked to another, whatever model you pick.

For context, the very first Track My Academy prototype had no database at all.
The Excel sheet was the database.
A long way from tenancy models.

FAQ

What is a tenant in SaaS?

A customer, usually an organisation, whose data and users are kept separate from every other customer's, even though they all use the same software.

Is a shared database with a tenant ID safe?

It can be, if every query is filtered by tenant and you add a database-level guard like row-level security. The risk is a single missed filter.

What's the difference between multi-tenancy and RBAC?

Tenancy keeps organisations apart. RBAC decides what each person can do inside their own organisation.

Sources

What next

How it started, Excel sheet and all: a coach complained, so I started a company.
And what happens when the shared building goes dark: the night I broke production.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages, and there's a free plan.

Shipping Android and iOS solo (iOS: coming soon)

Fri, 30 Oct 2026 08:30:00 +0000

I built the Track My Academy mobile apps myself.
Both of them. Android and iOS.

The Android app is live in production.
The iOS app is coming soon.

That second line is the honest one.
It's also the one every solo founder ends up writing at some point.

So this post isn't a victory lap.
It's a look at what actually stands between one person and two app stores.
Fees, rules, testers, reviewers.
And why, for a product like ours, I think Android first is the sensible order.

Photo: Denny Müller on Unsplash

Building it is the part you expect

Track My Academy started as a web app, and the web app is live.
Real academies run on it.
The first version came together with AI tools, mostly vibe coding, in about three months.
That story, and the agency build that came before it, is in the app that arrived from 2006.

The stack behind it is React, FastAPI, MongoDB, Supabase, Firebase and a few friends.

Here's the thing nobody tells you when you're writing code at night.
Writing the app is the part you can control.
Getting it into a store is a different job, with somebody else's rules.

The two doors: Play Console and App Store Connect

Each platform has one front door.
On Android it's the Play Console.
On iOS it's App Store Connect, which needs a paid Apple Developer Program membership.

The price of entry is the first difference.

	Google Play	Apple App Store
Account cost	US$25, one time	$99 a year
Identity checks	Government ID and a card in your legal name may be asked for	Legal name for individuals; a D-U-N-S Number for organisations
Beta testing	Closed testing tracks	TestFlight, up to 10,000 external testers

For a bootstrapped team, one fee is a rounding error and the other is a yearly subscription.
Neither is the real obstacle.
But it does tell you something about how each store thinks.

Apple's organisation route has its own homework.
Apple's enrolment page says an organisation must be a legal entity that can sign contracts, needs a D-U-N-S Number, and needs a public, working website on its own domain.
The organisation's name then shows as the seller name on the App Store.
None of that is hard.
All of it takes time you didn't plan for.

Google's 12 testers and 14 days

Android is not a free pass either.

If you open a personal Play developer account today, you can't just upload and publish.
Google's rules for personal accounts created after 13 November 2023 say at least 12 testers must be opted in to a closed test when you apply for production access.
And they must have stayed opted in for the preceding 14 days, continuously.

For a big company, 12 testers is a Slack message.
For a solo developer, it's a favour you ask of friends, family and anyone who owes you one.
Then you wait two weeks and hope nobody uninstalls.

My opinion: it's annoying, and it's also fair.
Two weeks with real people on real phones finds bugs you won't find alone.

Apple's reviewers read the guidelines so you have to

On iOS the gate is a human review.
Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours.
That's quick.
Passing is the slower bit.

The same page says that, on average, over 40% of unresolved issues relate to guideline 2.1, App Completeness.
The App Store Review Guidelines put it plainly: submissions "should be final versions with all necessary metadata and fully functional URLs included".
Placeholder text and temporary content have to go.

There's also a line I like for its honesty.
If your app has a login, include demo account details "(and turn on your back-end service!)".
Someone clearly learned that the hard way.

A product like ours is almost entirely behind a login.
It's role-based, so different people see different things.
So a reviewer needs a working account and enough data to see the app do its job.

Then there's guideline 4.2, Minimum Functionality.
Your app "should include features, content, and UI that elevate it beyond a repackaged website."
If you already have a good web app, this is the trap.
Wrapping it and shipping it is the fastest route, and the one most likely to bounce.

Apple's list of common problems also includes broken links, a missing privacy policy, inaccurate screenshots and unclear data-access prompts.
Boring things.
The boring things are always the ones that get you.

Why Android first, for us

Here's where I'll be opinionated.

In India, Android isn't the bigger platform.
It's nearly the only one.
StatCounter's figures for September 2026 put Android at 93.89% of mobile OS share in India and iOS at 6.05%.

Track My Academy is for sports academies.
Attendance, fees, player reports, messages to parents.
The coach who started all this ran everything from his phone.
His story is in how a coach's complaint turned into a company.

If you're building for that person in India, the odds say their phone runs Android.
So for an Indian sports-academy product, I think Android first is simply the order the market hands you.
Add a one-time fee and a review flow you can test yourself, and the choice makes itself.

That doesn't make iOS optional.
Some parents and owners will be on iPhones.
And the web app covers anyone in between while the iOS app is still on its way.

What I'd tell another solo dev

Budget for the store, not just the code. Fees, verification, screenshots, privacy policy, demo accounts.
Line up your testers early. On Play, 14 days only starts once they're in.
Read guidelines 2.1 and 4.2 before you build, not after. It's cheaper to design for them.
Ship where your users are first. For us, that's Android.
Say "coming soon" out loud. It's fine. It beats pretending.

The iOS app is coming soon.
When it's out, you'll hear about it here.
Probably with too many exclamation marks.

FAQ

Is the Track My Academy iOS app out?

Not yet. The Android app and the web app are live. The iOS app is coming soon.

Do new Google Play developers need testers before going live?

Personal accounts created after 13 November 2023 need at least 12 testers opted in to a closed test for 14 days in a row before applying for production access.

How much does it cost to publish on both stores?

Google Play charges a US$25 one-time fee. The Apple Developer Program costs $99 a year.

Sources

What next

How the product got built in the first place: the app that arrived from 2006.
And what happens after you ship: we blamed our code, it was SSL.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages.

I built a pager for my own developers

Thu, 29 Oct 2026 08:30:00 +0000

An earlier post ended with a promise.
Sort of.

In the night I broke production, an expired SSL certificate on our backend domain failed silently.
It took us about four hours to find it.
I stayed in the office all night.

At the end I mentioned, almost in passing, that I later built a "Pager System" for Track My Academy developers.
An internal, real-time error and notification system.
The idea: problems should find developers, not wait to be found.

This post is about that idea.
Why a tiny team needs a pager at all.
And what I think a good one should and shouldn't do.

A very old idea

Pagers were not invented for developers.
They were invented for doctors.

According to Wikipedia's history of the pager, Al Gross patented the first telephone pager system in 1949, intended for physicians.
The physicians, apparently, did not love the idea of being permanently on call.
I relate.

A year later, a paging service for doctors launched around New York City.
Doctors paid US$12 a month for a pager that worked within about 40 km of one transmitter.

And pagers never quite died.
Wikipedia notes that in 2017 the UK's NHS was thought to use over 10% of the world's remaining pagers.
Volunteer firefighters and rural first responders still carry them.

The point of a pager has never changed.
Something important is happening.
The right person needs to know.
Now, not when they next check.

Photo: Winston Chen on Unsplash

Why a small team needs one

Big companies have on-call rotations, incident commanders and very serious dashboards.
Small teams have a group chat and hope.

Hope is not a monitoring strategy.
I found that out the hard way, overnight.

Track My Academy runs on React, FastAPI, MongoDB, Supabase, AWS EC2, Vercel, Razorpay, Firebase and Redis.
That's a lot of moving parts for a small team.
Any one of them can have a bad day.
And real academies run on it, so their bad day becomes our bad day.

The awkward truth is that a small team can't afford to watch everything.
Nobody is sitting in front of a dashboard all day.
We're shipping features, fixing bugs and, in my case, occasionally attending class.

So the system has to do the watching.
And when something breaks, it has to come and find a human.

The rules I'd steal from Google

Google's SRE book has a chapter on monitoring distributed systems.
I keep going back to it.

Three lines from it should be on every developer's wall:

"Every page should be actionable."
"Every page response should require intelligence."
"Pages should be about a novel problem or an event that hasn't been seen before."

If a human gets woken up and the fix is a script, automate the script.
If the alert is something they'll ignore, delete the alert.

The same chapter splits monitoring into two questions: "what's broken, and why?"
What's broken is the symptom.
Why is the cause.

That distinction would have saved us hours.
We had a symptom: everything was down.
We jumped straight to a cause we'd picked ourselves: our new code.
The real cause was a certificate nobody was watching.

It also lists four golden signals: latency, traffic, errors and saturation.
If you can only measure four things, the book says, measure those.

There's a catch with alerting.
Too much of it is almost as bad as none.

The SRE book says that "when pages occur too frequently, employees second-guess, skim, or even ignore incoming alerts".
And one line I really like: "I can only react with a sense of urgency a few times a day before I become fatigued."

Hospitals know this problem well.
The US agency AHRQ has a primer on alert fatigue.
It describes one study where ICU monitors generated "more than 2 million alerts in one month", or "187 warnings per patient per day".
It also says clinicians "override the vast majority" of computerised ordering warnings.

Doctors are not careless.
They're human, and humans tune out noise.
Developers are the same, only with worse posture.

This is opinion, not a spec.
But if you're a small team building your own, here's what I'd aim for.

Page on symptoms users feel. Errors, slow responses, failed payments. Not every log line.
Say what's broken in one sentence. The person reading it may have just woken up.
Go to the right person. Not the whole team. One owner per alert.
Stay quiet when things are fine. Every alert that isn't urgent teaches people to ignore the urgent ones.
Watch the boring stuff. Certificates, domains, disk space, expiring keys.
Get pruned regularly. If an alert fired and nobody acted, change it or remove it.

You don't have to build it from scratch either.
Tools like Sentry let you send notifications or create tickets when issues match rules you set.
Its docs say the goal is alerts that are "valuable and not too noisy".
They suggest using filters so you only hear about issues your team needs to know about.

About those certificates

The boring stuff deserves its own section, because it got us.

Certificates are about to expire a lot more often.
In 2025 the CA/Browser Forum passed a ballot to cut the maximum TLS certificate lifetime from 398 days to 47 days.
The reductions start in March 2026 and finish in March 2029.

Meanwhile, Let's Encrypt stopped sending expiry reminder emails on 4 June 2025.
Its reasons included that more people now have reliable renewal automation.
It pointed people to third-party monitoring instead.

So: shorter lifetimes, fewer reminders.
If your renewal automation ever quietly fails, nobody is going to email you about it.
Your users will tell you instead.

Automate renewals.
Then monitor the automation anyway.

The point

A pager isn't about being available all the time.
Honestly, I'd like to sleep more, not less.

It's about not spending four hours blaming the wrong thing.
The problem should arrive with a name attached.
Then the human can do the part that needs a human.

FAQ

Does a small team really need alerting?

I think so. Small teams have fewer people watching, so the system has to do the watching for them.

What should trigger a page?

Something urgent, actionable and user-facing. If nobody needs to act right now, it's a ticket or a report, not a page.

How do I avoid alert fatigue?

Fewer, better alerts. Review the ones that fired, and delete or fix any that nobody acted on.

Sources

What next

The full outage story is in the night I broke production.
For where the late nights happen, see three monitors, one Monster can.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages.

How to win a hackathon, according to a tired judge

Wed, 28 Oct 2026 12:30:00 +0000

Cover photo: Evan Marvell on Unsplash

On 8 and 9 October, I sat on the other side of the table.

I was on the jury of a hackathon at VISTAS.
It was run by the Department of Computing Sciences and the Vels Innovation Council.
More than 80 teams turned up.
Over two days, I evaluated somewhere between 20 and 30 of them.

I've been a hackathon participant.
I've lost hackathons.
I've won a couple too, which my about page mentions with suspicious frequency.

Now I've judged one.
The personal story of that loop is in from hackathon loser to hackathon jury.

This post is the practical bit.
How to win a hackathon, from someone who just spent two days scoring them.

What hackathon judges actually see

Here's the part nobody tells participants.

Your judge isn't seeing your project in isolation.
They're seeing it as team number seven.
Or team number fourteen.

Most teams in a judge's group share the same or similar problem statements.
So the judge has already heard your problem explained.
Several times.
Usually in the same words.

Around the fifth team, focus starts slipping.
Not because judges don't care.
Because judges are human.

There's research on this, sort of.
Decision fatigue describes decisions getting worse after a long run of them.
The evidence for it is honestly mixed, so don't build a religion on it.
But anyone who has judged fifteen pitches in a row will nod politely.

Running order matters too.
A Carnegie Mellon study found later performers got higher marks.
That was Eurovision and figure skating, not hackathons.
You can't choose your slot anyway.
So the only thing you control is how fast you earn the judge's attention.

Photo: Herlambang Tinasih Gusti on Unsplash

The first 30 seconds of your hackathon pitch

Start like a person, not a slide deck.

Give the judge a firm handshake.
Ask them how their day is going.
They'll appreciate it.
It's probably been a long one.

Then introduce yourself and your team.
Clearly.
Confidently.
Names, and who built what.

Then say three things, fast:

The problem statement you picked, in one line.
The scope you chose to tackle within it.
Your solution, in one sentence a tired person can repeat.

That's it.
You now have the judge's attention, and you've spent maybe thirty seconds.

An elevator pitch usually runs thirty seconds to two minutes.
Your opening should sit at the short end.

Show the prototype early

The demo is the hackathon.
Everything else is decoration.

Plenty of hackathon rulebooks say this out loud.
The UH CodeRED rules, for example, strongly encourage a demo.
They say pitches and presentations are discouraged.
They even say teams aren't judged on the quality of their pitch.

Not every hackathon works that way.
But almost every judge prefers seeing a thing work to hearing about it.

So get to the prototype quickly.
Show the main flow, end to end.
One happy path that works beats five half-loaded features.

If something breaks, say so and move on.
Judges have seen broken demos before.
I've broken production, so I'm in no position to judge that part.

Photo: Shibraj Deb on Pexels

How to win a hackathon: stay on the problem statement

This one hurt to watch, because I used to do it.

Teams drift.
They start on the given problem statement.
Then they bolt on a chatbot, a dashboard and a dream.
By the end, the judge can't find the original problem.

Your score is usually tied to the problem you were given.
Solving a different, cooler problem rarely earns bonus points.
It mostly earns confused faces.

Before you build anything, write the problem statement on a sticky note.
Every feature must point back to it.
If it doesn't, it waits for version two.
I run my own life off sticky notes, as my desk setup post proves.

Don't over-engineer your hackathon project

The second classic mistake: building a cathedral in two days.

Microservices.
Three databases.
A custom login system nobody asked for.
And a demo that loads forever.

Judges don't score your architecture diagram.
They score what they can see working.

Pick the boring stack you already know.
Build the smallest thing that proves your idea.
Spend the saved hours polishing the one flow you'll demo.

When I started building Track My Academy, the first night ended with a landing page.
Not an architecture.
A landing page I actually liked.
Small, finished things build momentum.

What the jury doesn't want to hear

Some things quietly drain your score.

Facts the judge already knows. They've read the problem statement. Probably several times today.
Statistics read off a slide. Especially ones an AI tool produced five minutes earlier.
A tour of everything you made with AI. Use AI tools, absolutely. Just don't make them the pitch.
Trying to impress instead of explain. Big words, no working product. Judges spot it instantly.

On AI: I'm a fan.
I once chased free AI trials across dozens of email accounts.
But the judge is scoring your thinking, not your prompt history.

Photo: Phil Hearing on Unsplash

A simple hackathon pitch structure

If you want a template, steal this one.

Hello (10 seconds). Handshake, how's your day, team intro.
Problem and scope (20 seconds). One line each. No essays.
Solution (15 seconds). One sentence, plain words.
Demo (most of your time). One flow, start to finish, working.
How you built it (30 seconds). Your stack, and one hard thing you solved.
What's next (10 seconds). One honest line. Then stop talking.

Then let the judge ask questions.
Answer them directly.
"I don't know yet" is a perfectly good answer.
Making something up is not.

Hackathon tips for the questions round

Questions are where good teams pull ahead.

Listen to the whole question.
Answer the question that was asked, not the one you rehearsed.
Let the person who built that part answer it.
Keep answers to a few sentences.

If a judge points out a flaw, agree if it's true.
Then say how you'd fix it.
That shows judgement, which is exactly what they're measuring.

FAQ

How do hackathon judges score projects?

It depends on the event, so read the rules first.
Common criteria are technical difficulty, design, completion and impact.
Most judges weigh what they see working more than what they hear.

How long should a hackathon pitch be?

As short as the rules allow.
Aim for under a minute before the demo starts.
Then let the working prototype do the talking.

Do you need a perfect product to win a hackathon?

No.
You need one flow that clearly works and clearly fits the problem statement.
Polish that, and be honest about the rest.

Go build something

If you're heading into a hackathon, good luck.
Keep it short, keep it focused, and show the thing.

I build products at TrackMy Tech, and I'm always happy to talk shop.
Book a call if you want a second opinion on your idea.
Or read about the app that arrived from 2006, my favourite cautionary tale.

R.I.P. smart ball v1: what smart football sensors taught me

Tue, 27 Oct 2026 12:30:00 +0000

We are gathered here today to remember smart ball v1.

It was a football.
It had smart football sensors inside.
It never shipped.

Rest in peace, little guy.
This is the eulogy, and also a beginner's guide to why hardware is hard.
If you have ever wanted to stuff electronics into a football, read this first.

It will save you some wires.
Possibly some eyebrows.

The idea: a football that knows it was kicked

I love football.
I love building things.
I was also fascinated by how adidas built its smart ball.
It was extremely expensive.
And as far as I could find, you couldn't just buy one.

Then the chance actually showed up.
While I was working with CP Sports, we had a tie-up with an agency.
That agency worked with a well-known sporting goods manufacturer in north India.
They had a good contact with a senior executive there.

In one discussion, they asked us a question.
"Can you build something that tracks player data like the adidas smart ball?"
"But cheaper?"
We didn't even flinch.
"Yes, of course."

They asked for a structural design within a week.
They'd help us pitch it to the company.
There was talk of hefty funding.
I genuinely thought my life was settled.

A low-cost football with sensors inside.
Something that could tell you about every touch.
How hard could it be?

Very.
The answer is very.

This was not a weekend hack, either.
Smart Football R&D ran from December 2024 to December 2025.
A full year of my life, inside a ball.

It ran alongside Track My Academy, which I was building at the same time.
That one started because a coach complained about attendance.
So yes, two big projects at once.
One of them was round.

Prototype zero: maida, boba straws and a pickleball

We had one week to show a structure.
We were second-year students.
We had no 3D printer.
We didn't even really know how 3D printing worked.

So I improvised.
The model just had to show the structure, in any shape or size.
I made a clay-like dough out of maida, plain flour.
I pushed it into boba straws to build the structure.
I used a pickleball as the core and stuck cones on it.

Yes, our very first smart ball prototype was partly made of flour.
We presented it anyway.
Everything went perfectly.
Hold that thought.

What was inside smart ball v1

Look at the photo above.

That's an open football shell.
Inside, there are piezo sensors around the edges.
In the middle, a breadboard covered in wires.

Lots of wires.
More wires than any football should legally contain.

Piezo sensors turn pressure into a small electrical signal.
Kick the ball, the sensor reacts.
At least, that's the theory.

Theory and breadboards are not always on speaking terms.

Photo: Vishnu Mohanan on Unsplash

A breadboard is brilliant for prototyping.
You push wires in, no soldering needed, and you can reuse it.

Wikipedia also politely notes its connections are "subject to jostle".

Jostle.
In a football.
The object whose entire job is being kicked.

You can see where this is going.

The year in one list

People imagine hardware R&D as one big "eureka".
It's more like a long list of small "oh no".

Here is what that year actually covered:

Sensor selection. Which sensor, how many, and what it should even measure.
Component placement. Where everything sits inside a sphere that gets booted.
Ball balance. Add weight on one side and the ball stops rolling straight.
Bladder and pressure research. The air inside changes how everything behaves.
Prototype testing. Kick it, check it, fix it, repeat.
App dashboard concepts. What a player or coach would actually see afterwards.

Every item on that list could be its own engineering degree.
I had a breadboard and optimism.

Ball balance was the sneaky one.
In software, a heavy function makes things slow.
In a football, a heavy component makes it wobble.
Nobody wants a ball that curves because of your circuit.

Our first PCB, made in Coimbatore

The breadboard could only take us so far.
So we designed our own custom PCB, a printed circuit board.
We went to a professional PCB printing place in Coimbatore.
We spent two full days there.

We came back with our first PCB.
We connected it to our own sensors.
And it worked.

I can't fully explain that feeling.
The sensors responding, with everything connected inside the ball.
You could see the joy in our eyes.
That moment taught us more about IoT devices than any course.

IMU vs piezo sensors: two ways to make a ball feel things

There are two common ways to give a ball a sense of touch.

Piezo sensors react to pressure and impact.
They are cheap, simple and good at noticing a sudden hit.
The catch: they cannot do truly static measurements.
They notice the kick, not the gentle story after it.

An IMU is an inertial measurement unit.
It combines accelerometers, gyroscopes and sometimes magnetometers.
It measures how the object moves and rotates.

The catch there is drift.
Tiny measurement errors pile up over time.
The device slowly loses track of where it really is.

So, roughly:

	Piezo sensor	IMU
Good at	Detecting impacts and pressure	Motion, spin and orientation
Weak at	Static or slow measurements	Drift over time
Beginner-friendly	Very	Less so

My opinion: piezo is the friendly place to start.
An IMU is where the serious connected ball technology lives.

Meanwhile, the professionals

While I was fighting wires, real sports tech was doing real things.

At the 2022 World Cup, the match ball had an IMU sensor in its centre.
According to FIFA, it sent data 500 times per second.
That helped detect the exact moment a ball was kicked, for offside calls.

adidas says a suspension system held that sensor steady at the centre.
It ran on a rechargeable battery, charged by induction.

Read that again.
They suspended a sensor in the middle of a ball.
That is the ball balance problem, solved properly.

500 times per second.
My prototype struggled to report once without a wire falling off.

Humbling?
Yes.

Inspiring?
Also yes.

Photo: Jason Mayer on Unsplash

The real engineer: Jitendra

Let me give credit where it's due.
A huge shout-out to Jitendra.

He was my junior, and I met him in my second year.
Geeky, nerdy, and with an immense knowledge of IoT and gadgets.
He built about 70% of the IoT systems that made the ball work.
He also wrote the code for it.

My part was product design.
I told him how I wanted it to work.
He made it work.
That's a very good deal for me.

I learned to solder (soldering safety first)

Soldering was the painful part for me.
Before this project, I had never soldered anything.

Complete beginner.
Absolute zero.

The smart ball got me soldering.
I look like a scientist.
I solder like a nervous chef.

But I learned.
Slowly.

If you're a beginner too, here's the bit to take seriously.

A soldering iron runs roughly between 200 and 480 °C.
That is not a "quick touch to check" temperature.
Hold it by the handle and put it back in its stand.

The fumes matter too.
The UK's Health and Safety Executive is blunt about it.
Rosin solder flux fume can cause asthma and dermatitis.
Their advice is simple: keep your face out of the fume and use extraction.

So my beginner soldering safety list:

Safety glasses on, every time.
Ventilation or a fume extractor.
Iron goes back in the stand.
Wash your hands after handling solder.
Never assume the tip has cooled down.

Photo: Blaz Erzetic on Unsplash

Why hardware is hard (and why v1 never shipped)

Hardware is hard.
Everyone says it.
Now I get it.

With software, a mistake costs you a deploy.
With hardware, a mistake costs you a ball.

Software also forgives you faster.
When I broke production for hours, at least nothing physical died.
You can't hotfix a solder joint over Wi-Fi.

Hardware also costs money at every single step.
Parts, more parts, replacement parts for the parts you fried.

Now, the plot twist I promised.
That hefty funding? It never came.
It was promised. It just never arrived.

We spent more than a year on R&D with basically no outside money.
We still put more than ₹1 lakh of our own into the ball.
Eventually, we had to stop.
We put the project aside, as a memory.

No dramatic explosion.
Just a deal that never landed, and a very sensible spreadsheet.

Smart ball v1 was never finished.
But it was never meant to be the final version.

That's what v1 is for.

Hardware prototyping for beginners: what I'd tell you

Building teaches you what reading can't.
I understood sensors only after I wired one wrong.
I learn by doing things badly first.
Same energy as rebuilding the app that looked like 2006.

Start on a breadboard, finish on solder.
Breadboards are for finding out.
Solder is for when you've found out.

Think about where the thing lives.
A circuit on a desk is easy.
A circuit inside a ball gets kicked, squashed and rained on.

Prototypes are allowed to die.
Their job is to teach you, not to survive.

Respect hardware people.
Anyone who ships a physical product is a wizard.
I'm still at the "please don't short-circuit" stage.

FAQ

What sensors are used in smart footballs?

Mostly IMUs, which track motion and spin.
The 2022 World Cup ball used one sampling 500 times per second.
Piezo sensors are a cheaper way to detect impacts, which is where I started.

Is a smart football hard to build as a beginner?

A basic "did it get kicked" prototype is doable.
A balanced, durable ball that survives real matches is properly hard.
Budget for broken parts and broken pride.

Is soldering safe for beginners?

It can be, with basic care.
Wear eye protection, keep your face out of the fume and use ventilation.
Treat the iron like it's always hot, because it usually is.

The funeral is over

Smart ball v1 lives on in my heart.
We still have the prototype.
We still have the design files.

I still think about the idea.
I still watch football and think about sensors.
Building Veeran made that worse, as I explain in this post.

If we get funding, we'll restart from exactly where we left off.
V2 might happen someday.
Sports tech is the whole point of TrackMy Tech, so never say never.

Until then, I'll keep the safety glasses close.

Building something in sports tech, hardware or software?
Book a call with me and we can compare scars.

Outsourcing vs building it yourself: our app arrived from 2006

Tue, 27 Oct 2026 08:30:00 +0000

Every founder has a moment where they say, "Fine. I'll do it myself."
Mine came with a very specific smell.
The smell of PHP and a design from another decade.

This post is about outsourcing app development vs building it yourself.
I've done the first one badly and the second one stubbornly.
So I have opinions.
Lots of them.

The idea was simple

It started with a coach complaining.
His students' fee payments just wouldn't tally.

Small problem.
Annoying problem.
The kind that sticks in your head.

That problem became Track My Academy.
The full origin story is in how a coach's complaint turned into a company.

At that point, I had basically zero real coding experience.
I'd made small, chota-chota apps.
But I had no idea how an app actually works in production.
Domains, servers, deployment: all a mystery.

What I did have was a business mindset.
How the product should look.
How we'd get customers.
How we'd get paid.
That's it.

So we did what sensible people do.
We looked for freelancers and found an agency.
The plan was to pay them for a white-label solution.

On paper, that's textbook outsourcing.
You pay an external provider to do work you'd otherwise do in-house.
Except we didn't really have an "in-house".
We had enthusiasm.
Enthusiasm is not a department.

Then the build arrived

I opened it.
I looked at it.
It looked back at me from 2006.
It looked like it had jumped straight out of a template from that year.

Photo: Siri louis on Unsplash

PHP.
A design that belonged in a museum.
The kind of interface that makes you check your calendar.

To be fair, PHP isn't the villain here.
Plenty of good software runs on it.
The design was the villain.
And, probably, so was our brief.

Not a single screen looked decent.
The thing technically worked.
But it looked so bad that nobody wanted to touch it.
I was ashamed to show it even to my friends.
That's how bad it was.

So we scrapped the whole thing.

I sat there and thought one clear thought.
"Damn. I'll do this myself."
I'd build it with AI tools, the way people now call vibe coding.

The stupidest ₹50,000 I've ever spent

Let me be honest about the price.
We paid that agency ₹50,000.
It's the stupidest way to spend 50k I can think of.

And it wasn't even my money.
It was my co-founder's.
He didn't take it too hard.
But I was responsible for that decision.
I still feel bad about it, honestly.

Outsourcing app development vs building it yourself

Here's my honest comparison, after one very educational PHP build.
These are opinions, not laws of physics.

Outsourcing makes sense when:

You know exactly what you want, down to the screens.
The app supports your business but isn't the business.
Someone on your side can review the code and the design.
You have budget for a second round. There's always a second round.

Building it yourself makes sense when:

The product is the business.
You'll be changing it every week for years.
You're willing to be bad at it for a while.
You'd rather understand every bug than pay someone to explain it.

Track My Academy was clearly the second list.
It's the company, not a side tool.

There's also a third option people forget.
Build the first version yourself.
Then bring in people who already understand what you're making.
For most student founders, that's where I'd point them.

How to write a product brief that doesn't come back from 2006

Here's the thing nobody tells you.

If you can't describe what good looks like, you won't get good.
You'll get whatever the builder thinks "done" means.

And their "done" might be from 2006.

Bigger companies write a product requirements document.
It says what the product should do, not how to build it.
You don't need forty pages.
You need one honest page.

Photo: Compagnons on Unsplash

My checklist for a one-page product brief:

Who it's for. "A coach with one batch" beats "sports organisations".
The one painful job. For us, that was attendance and payments.
Three apps you like the look of. Screenshots, not adjectives.
What "done" means. Which screens, which actions, which devices.
What you won't build yet. This list saves more money than any discount.
Who checks the work. If nobody can read code, say so upfront.

Point three is the one I'd underline twice.
"Modern and clean" means nothing.
Every design was modern and clean once.
Even in 2006.

The aim is a minimum viable product.
That means just enough features for early users to actually use it.
Then their feedback tells you what to build next.
Not your imagination at 2 a.m.

The first night of building a SaaS MVP myself

My setup was not exactly a startup lab.

A MacBook Air.
A second-hand iPhone my cofounder got me.
ChatGPT.
VS Code.

That was the entire tech stack of my ambition.

Did I start coding immediately?
No.
Mostly, I researched.

How do real products look?
How do people structure an app like this?
Why does everything I write look worse than everything I see?

By the end of it, I'd built a landing page.
A landing page I actually liked.
That was the night I stopped waiting for someone else.

Building it properly took about three months.
The first working version alone took more than a month and a half.
Changes, then more changes, then changes to the changes.

When I look at that first version now, I'm honestly embarrassed.
It might be the worst thing that ever happened to a piece of software.
The version we have today? I'm really proud of it.

I learn by touching the thing until it makes sense.
That means doing it badly first, then slightly less badly.
The AI help came from wherever we could find it.
That story is in dozens of email accounts and zero shame.

The modern stack I ended up with

No PHP this time.
Again, nothing against PHP.
I just needed a fresh start and a clean conscience.

Here's what Track My Academy runs on:

React for the web front end.
FastAPI, a Python framework for building APIs with type hints.
MongoDB, a document database.
Supabase, which bundles Postgres, auth, storage and realtime features.
AWS EC2 and Vercel, where things actually run.
Razorpay, the payments gateway.
Firebase and Redis, quietly doing their jobs in the background.

None of this is exotic.
It's just current.
And I can explain why every piece is there.

That's my real advice for anyone outsourcing.
Ask the builder, "Which stack, and why?"
If the answer is "it's what we always use", that's information.
Treat it like a yellow card.

Knowing the stack also means knowing exactly how to break it.
I proved that when I took production down for hours.
Ownership cuts both ways.

Then I built the Android and iOS apps too

The web app wasn't the end.
Coaches aren't sitting at desks.
They're on a pitch, holding a phone and a whistle.

So I built the Android and iOS apps for Track My Academy.
The Android app is live in production.
The iOS app is coming soon.
Apple reviews things slowly. So do I, to be fair.

Photo: Daniel Romero on Unsplash

This is where building it yourself pays off.
I'd built the backend, so I knew it inside out.
The apps were new screens, not new mysteries.

If I'd outsourced the web app, the mobile apps would've started from zero.
Or from 2006 again.
I'm not sure which is worse.

Today Track My Academy covers attendance, fees, player analytics and parent communication.
Real academies run on it.
It's multi-tenant and role-based, which is a fancy way of saying "complicated".
It works on the web and Android, with iOS coming soon.
It's published by TrackMy Tech, our bootstrapped sports-tech company.

What I learned from the 2006 build

I'm not angry at the agency that built it.
Okay, a little.
Mostly at myself.

Outsourcing works when you know what you want.
It doesn't work when you're hoping someone reads your mind.

Building it myself meant I understood every piece.
When something breaks, I know where to look.
When a coach wants a feature, I know what it costs.

None of that exists if I'd accepted the museum piece.

So, should you build it yourself?
Not always.
But if what comes back makes you wince, listen to the wince.

Your irritation is data.

Mine turned into a company.
Yours might turn into something too.
Or at least into a better landing page.

I'll take either.

FAQ

Is it cheaper to outsource app development or build it yourself?

Outsourcing usually looks cheaper on day one.
Building yourself costs time instead of money.
Outsourcing costs money, then often time anyway, in revisions.
If the product is your business, I'd rather pay with time.

What should a product brief for a developer include?

Who it's for and the one painful job it solves.
Three reference apps, with screenshots.
A clear definition of done, and a list of what's out of scope.
And who will review the work before you pay for it.

Can a non-technical founder build a SaaS MVP?

I was a bio-maths student in class 12.
That story is in how I ended up in computer science.
So yes, eventually.
Expect to be bad at it first.
That's the tuition fee.

Your turn

Run a sports academy and tired of spreadsheets?
Try Track My Academy.

Stuck deciding between outsourcing and building it yourself?
Book a call with me and we can argue about it.

Or see where all this happens now, in my three-monitor desk setup.

A coach complained, so I built sports academy management software

Tue, 27 Oct 2026 04:30:00 +0000

Cover photo: Adrià Crehuet Cano on Unsplash

Most startup stories begin with a vision.
Mine began with a complaint.

Not even my complaint.
Two other people's.

This is the story of how Track My Academy started.
It is sports academy management software now.
Back then, it was one tired coach, one frustrated academy owner and a messy spreadsheet.

I'm writing it down because people keep asking where the idea came from.
The honest answer is less heroic than they hope.

The evening it started

I was coaching football part-time at a sports academy.

Nothing glamorous.
Cones, whistles, and a lot of shouting about passing.

One evening, I noticed a coach struggling with his phone.
He was trying to match his students' fee payments.
On one side, the payments in his Google Pay account.
On the other, the manual entries he'd been writing down.
They didn't tally.

I asked the obvious question.
"Why don't you just use an Excel sheet?"

His answer was very honest.
He runs everything from his phone.
Keeping an Excel sheet updated every time just wasn't happening.

The academy's owner was listening.
He's now my co-founder, which tells you how this story ends.
He asked me something simple.
"Why don't you build a small app for these guys?"

Coaches would enter their payment details.
Everything would land in an Excel sheet automatically.
No more tallying at night.

Photo: Adrià Crehuet Cano on Unsplash

The first prototype: a spreadsheet pretending to be an app

So I built the simplest thing possible.
It didn't even have a database.
The Excel sheet was the database.
Yes, really.

The app was just a small form.
A coach entered how much they'd received.
They pasted the payment ID from Google Pay.
Done.

The entry dropped straight into the sheet.
The sheet was shared automatically.
The owner could open it any time and see everything.

It was ugly. It was tiny. It worked.
That was the very first prototype of Track My Academy.

From one academy to "wait, why not everyone?"

Then a thought hit me.
Hey, wait.
Why can't I sell this to other people?

Plenty of academies had exactly this problem.
Fees tracked on paper, phones and memory.
And player training was just as messy.
Who attended. Who improved. Who needs more work.

So the payments form grew up.
It became sports academy management software.
Later, it also became a sports analytics tool, in the same app.
How the analytics got in there is a story for another post.

Why sports academy management software is a boring problem worth solving

Here's something nobody tells you about startups.
The best problems are usually boring.

Attendance registers. Fee reminders. Who paid. Who didn't.
Nobody makes a film about fee reminders.

But coaches deal with this every single day.
And every hour spent on paperwork is an hour not spent coaching.

That's not boring to them.
That's their whole evening.

Paul Graham has a name for why people skip these problems.
He calls it schlep blindness.
Your brain quietly hides ideas that involve tedious work.

Jared Friedman says something similar in YC's talk on getting startup ideas.
His example is Gusto, which makes payroll software.
Lots of programmers knew payroll software was bad.
Nobody fixed it, because it was boring.

Sports admin is the same flavour of boring.
Which, in my opinion, is exactly why it was worth doing.

Attendance tracking for sports academies

Let's start with the original villain.

Attendance tracking for sports academies sounds trivial.
It is not.

Batches change.
Kids switch timings.
Some coaches cover two branches.
Somebody always forgets the register at home.

Paper works until it doesn't.
Then you're reconstructing last month from memory and a WhatsApp group.

Photo: Billy Albert on Unsplash

In Track My Academy, attendance is the boring core.
Check-in can be by QR code, biometric or the mobile app.
Coaches get alerts when someone is absent.

That last bit matters more than it sounds.
A missed session is a small signal.
Three missed sessions is a conversation with a parent.

Fee collection and reminders without the awkwardness

Then there's money.

Nobody likes chasing fees.
Coaches especially hate it.
They signed up to teach a sport, not run accounts receivable.

So the software handles fee collection and reminders.
Invoices go out.
Reminders go out.
Payments get recorded.

The coach doesn't have to be the bad guy at the gate.
The system can be the bad guy.
Systems don't mind.

The stack includes React, FastAPI, MongoDB, Supabase and Razorpay.
Plus a few friends I won't list here.
I'll spare you the architecture diagram.

Attendance and fees were the complaint.
But once the data was in one place, more became possible.

Player progress tracking was the obvious next step.
Coaches can log performance and see trends over time.
Pace, endurance, accuracy, skill.

Parents can see shareable player reports on their phone.
Which, frankly, saves a lot of "so how is he doing?" chats after training.

Photo: Jamie Street on Unsplash

Parent communication lives there too.
Announcements, session updates and direct messages.
No more screenshotting the timetable into six groups.

It's a software as a service product.
The academy doesn't host anything.
It just logs in.

It's also multi-tenant.
Many academies can share one system, each with separate data.

And it uses role-based access control.
Owners, coaches and parents each see what their role allows.
A parent should not be able to edit the fee ledger.
Tempting as that might be for them.

There's a web app and an Android app.
The iOS app is coming soon.
I built the mobile apps myself.
That sentence is doing a lot of heavy lifting.

And real academies run on it.
That part still feels slightly unreal.

From a 2006-looking app to building it myself

The road there was not straight.

For the full product, we first hired someone to build it.
What came back was PHP, terrible design, and looked like 2006.
I wrote about the app that arrived from 2006 separately.
It is a whole saga.

So I decided to build it myself.

The first night was a MacBook Air.
A second-hand iPhone my cofounder got me.
ChatGPT and VS Code.

Mostly research.
Then a landing page I actually liked.

I learn by touching the thing until it makes sense.
Usually by doing it badly first.

Later came the less glamorous lessons.
Like hunting free AI trials across dozens of email accounts.
And the night I broke production by splitting the backend.

TrackMy Tech, CP Sports, and the titles I didn't expect

Track My Academy started in December 2024.

Since June 2026, it has a proper home.
TrackMy Tech Pvt Ltd is the sports-tech and SaaS company that publishes it.
It's bootstrapped.
I'm its Executive Director.

Which still sounds funny to me.
I'm also a student.
The exams have not been informed of my title.
More on that in exams, the office and a 1 a.m. gate.

Separately, I'm Technical Operations Manager at CP Sports.
I built its first official website and internal academy and event tools.
I also manage the digital team and coordinate coaches across branches.

That job keeps me close to how academies actually run.
Veeran came later, built at TrackMy Tech.

What coaching taught me about building

Coaching and building products are weirdly similar.

You can't redo the first half.
Football has twenty-two players, ninety minutes, and no undo button.
Production software feels exactly the same.

Listen more than you talk.
That coach didn't pitch me a startup idea.
He just couldn't make his payments tally.
The idea was hiding inside the complaint.

Fix what people actually do.
Coaches don't want dashboards for fun.
They want to finish admin and get back to the pitch.

Photo: Connor Coyne on Unsplash

Finding startup ideas in real complaints

Stop looking for big ideas.

Paul Graham puts it neatly in How to Get Startup Ideas.
The verb you want is not "think up".
It's "notice".

Go and sit near people doing their actual jobs.
Wait for them to complain.

Write down the complaint.

Then ask a few annoying questions.
How often does this happen?
What do you do about it now?
Would you pay to never deal with it again?

If the answers are "daily", "a spreadsheet" and "yes", congratulations.
You may have a company.

It won't sound exciting at a party.
It will sound very exciting to the person who has that problem.

And honestly? Parties are overrated anyway.
I'd rather be at the office.

Which is probably a problem of its own.

FAQ

What is sports academy management software?

It's software that runs the admin side of a sports academy.
Attendance, fees, player progress and parent messages, in one place.
Ideally, so the coach can go back to coaching.

Does Track My Academy work on phones?

Yes.
There's a web app and an Android app, and the iOS app is coming soon.
Coaches and parents mostly live on their phones anyway.

How do I find a startup idea?

Notice problems instead of inventing them.
Boring, repeated, slightly embarrassing problems are the best ones.
Then check whether people would actually pay to make them go away.

Try it, or talk to me

If you run an academy, take a look at Track My Academy.
There's a free plan, so the risk is mostly your time.

If you'd rather talk it through, book a call with me.

Or read how the smart football prototype went.
Spoiler: it's in the title.

Production outage lessons: we blamed our code. It was SSL.

Mon, 26 Oct 2026 12:01:40 +0000

Building a product is one job.
Keeping it alive is a completely different job.

Nobody warns you about the second one.
Or they do, and you don't listen.
I didn't listen.

This post is my production outage lessons, learnt the expensive way.
One backend split, one expired SSL certificate, four hours of blaming the wrong thing.
And what I'd do differently: checklists, rollbacks, monitoring and postmortems.

The clever idea: splitting the backend

This happened in 2026, not long after we incorporated TrackMy Tech.
We'd just become a private limited company.
And we had a nagging feeling we weren't doing things professionally enough.
We wanted to fix that.

We also had real problems.
Lots of payment-related issues.
A steady stream of API errors.
And the load wasn't balancing well.

Then an Instagram reel showed up.
I shared it with the team.
"This model is so capable. We can try some serious stuff with it."
That one reel kicked off the whole cycle.

The plan: split the backend into separate pieces.
We used an AI coding agent to do the heavy lifting.
To be fair to the agent, it did its job.
It was us who got things wrong.

On paper, splitting load sounds smart.
Spread the work. Feel like a real engineering team.
Put "distributed" in your head and feel tall.

Then everything went down

Not slowly. Not politely.
Everything went down.
For hours.

If you've never broken production, let me describe the feeling.
Your stomach drops to somewhere near your shoes.
Every message notification sounds like an accusation.

Real academies use Track My Academy.
Real coaches. Real parents. Real attendance.

None of them care about our clever architecture.
They care that the app works.

And it did not work.

Photo: Taylor Vick on Unsplash

The real culprit: an expired SSL certificate

We were sure we'd broken the code.
So we did what any panicking team does.
We checked the split.
We checked the code.
Then we checked it all again.

About four hours later, we found it.
It wasn't the code at all.
The SSL certificate on our backend domain had expired.
Right in the middle of the transition.

It was failing silently.
And we were busy blaming our own clever architecture.

When we finally saw it, we just stared at the screen.
Oh God.
This is why debugging is hard.

Here's why it's so sneaky.
A TLS certificate proves a server is who it claims to be.
Every certificate has a "Not After" date.
After that date, it's simply no longer valid.
Apps and browsers stop trusting the server, and requests fail.

Short certificate lifetimes are normal now.
Let's Encrypt says its default certificates are valid for 90 days.
It recommends renewing them every 60 days.
Miss a renewal and the clock just quietly runs out.

The timing is what fooled us.
Two things changed at once: our backend, and the certificate's validity.
So naturally we blamed the change we'd made ourselves.

Google's SRE book says roughly 70% of outages come from changes to a live system.
We were the change.
We just weren't the cause.

The longest night in the office

I stayed in the office all night.

Not because it looks dedicated on LinkedIn.
Because it was my mess, and I wanted it fixed.

There's a special kind of quiet in an office at 3 a.m.
It's just you, the monitors, and your mistakes.

The Monster cans on the wall were not decoration that night.
They were fuel.
(The full tour of that desk is in three monitors, one Monster can.)

Office nights are not rare for me, sadly.
That's a whole other post: exams, the office and a 1 a.m. gate.

When I'm stuck badly enough, I call Arun

Every founder needs one person who picks up at any hour.
For me, that's Arun. Our CTO.

No questions asked. He just picks up.
At any hour. Which is frankly suspicious.

If you want to know who he is, here's his portfolio.
He's the reason "stuck" never becomes "stuck forever".

The lesson here isn't technical.
Know who you'll call before the crisis, not during it.

A deployment checklist I'd hand my past self

I'm not going to pretend I have a grand theory.
But here's the checklist that night burned into my brain.

Check the boring stuff first. SSL certificates, DNS, environment variables. Then blame the code.
Know when every certificate expires. Write the dates down before you touch anything.
Change one big thing at a time. Two changes, one failure, endless guessing.
Deploy when people are awake. Ideally the people who can fix it.
Know your way back. Before you ship, not after.
Watch it after you ship. "Deployed" is not the same as "working".

Google's SRE book lists three practices for safer changes.
Progressive rollouts.
Quickly and accurately detecting problems.
Rolling back safely when problems arise.

That's basically my checklist, written by people with far more sleep.

Photo: Jakub Żerdzicki on Unsplash

Rollbacks: have a way back

If you can't undo a change quickly, you're not deploying.
You're gambling.

One classic pattern is blue-green deployment, as Martin Fowler describes it.
You keep two nearly identical production environments.
One is live. The other gets the new version.
You test the idle one, then switch the router over.

If it breaks, you switch the router back.
Fowler calls it "a rapid way to rollback".

You don't need a fancy setup to steal the idea.
Keep the old config. Keep the old build.
Know the exact command that puts things back.
Practise it once on a calm day.

Monitoring and alerting: find out before your users do

The worst way to discover an outage is from a user.
The second worst is from a friend asking "is your app down?"

The Google SRE chapter on monitoring distributed systems is a good start.
It names four golden signals: latency, traffic, errors and saturation.
Measure those and page a human when they look wrong.
I'd add one more for small teams: certificate expiry dates.
That gets you decently covered, according to the book.

It also says something I love: "Every page should be actionable."
An alert you ignore is just a very expensive ringtone.

Later, I built a "Pager System" for Track My Academy developers.
It's an internal real-time error and notification system.
The idea is simple: problems should find developers, not wait to be found.

Photo: Luke Chesser on Unsplash

Write the postmortem, and keep it blameless

After the fix, the temptation is to sleep and never speak of it again.
Don't.

Write an incident postmortem.
Google's chapter on postmortem culture puts it nicely.
"Writing a postmortem is not punishment."
It's a learning opportunity for the whole company.

Their triggers include user-visible downtime and an engineer having to roll back.
A multi-hour outage ticks both boxes with enthusiasm.

Atlassian's guide to incident postmortems is very practical.
It covers a timeline, root cause, impact, metrics and action items.
It suggests a review meeting within 24 to 48 hours of resolution.
Then draft the write-up straight after.
Wait longer and the details evaporate.

Blameless doesn't mean nobody made a mistake.
It means you fix the system so the next person can't make it.
Even if the next person is, once again, me.

Was it worth it?

Honestly? Yes.
Not the outage. The outage was terrible.
But I learned more in that one night than in a month of tutorials.

Mistakes are expensive teachers.
They're also very, very memorable.

I'd still prefer the tutorials, though.

FAQ

What are the most important production outage lessons for a small team?

Change one thing at a time.
Always have a tested way back.
Monitor the basics so you hear about problems before users do.

Can an expired SSL certificate take down a backend?

Yes, and quietly.
Once a certificate passes its expiry date, clients stop trusting the server.
Requests fail, and it can look exactly like a code bug.

What should go in an incident postmortem?

A timeline, the impact, the root cause and clear action items.
Keep it blameless.
Fix the system, not the person.

Sources

What next

Curious how the product got built in the first place? Read the app that arrived from 2006.
Or how I learned the tools: dozens of email accounts and zero shame.

Running an academy? Track My Academy handles attendance, fees, player analytics and parent communication.
It's built by TrackMy Tech.

Want to talk shipping, breaking and fixing things? Book a call.

You’re Losing Money. Your Instinct Says Cut. Your Instinct Is Frequently, Precisely Wrong.

Fri, 23 Oct 2026 05:55:33 +0000

Part 4 of 4 on IBR's Mini Strategy Handbook for AI Founders. The last review is a five-minute finance lens that would have saved a lot of businesses I've watched shrink themselves to death.

Here’s the situation the handbook closes on, and if you’ve run anything, you’ve lived it. Revenue has plateaued. Every month closes red. You do the responsible thing: cut marketing, freeze hiring, trim every discretionary line. And the loss… doesn’t move. Or deepens. So you cut again, more responsibly, and it deepens again, and at some point somebody says the word “shut” in a meeting.

Vivek Bisht’s The Contribution Factor argues that a lot of these businesses aren’t broken. They’re sub-scale, and every “responsible” cut makes them smaller and therefore worse. The tool that tells the two apart is one subtraction.

The formula, and where your next order actually goes
Contribution Factor = Price − Variable Cost per Order. It’s what’s left from each sale after paying the costs of making that sale, and it “contributes” toward the fixed costs, rent, salaries, software, until those are covered, after which every further order is profit.

That’s genuinely the whole thing. But the diagnostic power comes from what the sign and scale of the number tell you to do, and it’s here that most founders’ instincts fail.

Negative: every sale loses money, scaling makes it worse, fix unit economics before anything else. Positive but low volume: the model works, you’re just too small to cover the cost base, so spend more, not less, and grow into it. Positive and covering fixed costs: you’ve crossed break-even; defend margins, reinvest selectively. The middle row is where a startling number of “failing” businesses actually live, and it’s exactly the row where cutting kills you.

The death spiral, and its reversal
The handbook’s case is Treya Gifts, an Indian DTC brand selling STEM toys for kids. Loyal customers, strong reviews, eighteen months of plateau and monthly losses, and the founders were doing the textbook thing: slashing marketing, freezing spend, trimming everything variable. Each round of cuts was followed by a proportionate drop in orders, and the losses persisted, because the same fixed costs were now spread across fewer orders. Every cut was defensible. The loop was fatal.

IBR rebuilt the P&L per order and the contribution factor came back clearly positive, about 33% of revenue. Treya wasn’t selling at a loss. It was sub-scale. So the recommendation was the opposite of every instinct in the room: increase marketing until volume comfortably cleared the fixed-cost barrier, with guardrails, cap cost-per-order below the contribution margin so every incremental order stayed profitable, shift toward channels with clean per-order attribution so you can watch the number live, and freeze fixed costs, no hires, no warehouse, until volume stabilized. Twelve weeks later: orders up 180%, contribution factor steady at 33%, fixed costs up 8%, and the business moved from monthly loss to monthly profit. Not by cutting. By spending more on the one line that was working.

Where I’d argue with a word: “responsible”
My quibble this time isn’t with the framework, it’s with the vocabulary founders use around it. Cutting costs when you see red ink is described, universally, as “responsible,” and spending more as “reckless.” The contribution lens shows the labels are backwards for a specific, common case. When each order is profitable and you don’t have enough of them, cutting the thing that produces orders is the reckless move dressed as prudence. It feels responsible because it’s painful and it’s what your board expects. Pain is not a signal of correctness. Ask Part 3.

The handbook flags the misclassification that causes most of this, and it’s the single most useful sentence in the review: performance marketing is a variable cost, not fixed overhead. File it under overhead and you will cut it at exactly the moment you should be doubling it.

The AI-startup edition, which the handbook leaves for us
The Treya case is e-commerce; the handbook is for AI founders. So let me draw the translation, because AI businesses have a variable-cost line that didn’t exist five years ago and that founders routinely misfile.

Inference tokens per job are variable. So are third-party API calls, human-review minutes, and payment fees. Salaries, cloud baseline, SaaS seats and the model you fine-tuned once are fixed. Which means an AI product can have a negative contribution factor while looking healthy on gross margin slides, if each job burns more tokens than the price covers, and it can be positive-but-sub-scale while looking doomed, if you’ve been treating the ads that bring jobs as overhead. Run the per-job P&L. Put the token bill in the variable column where it belongs. Then read the number and decide, from the table above, not from your stomach.

One more AI-specific wrinkle: token prices fall. A negative contribution factor today may be positive in two quarters with no change on your side, which is the only case I know where “wait” is a legitimate unit-economics strategy. Note it, date it, and don’t confuse it with the sub-scale case, which waiting only worsens.

Closing the series
Four reviews, one arc. Launch wide and win by what you cut. Distribute through a specific person with a specific scar, because polish is free now. Read every signal by what it cost the customer to send. And when the numbers still come back red, decide (this one) with one subtraction whether you’re broken or merely small, because the fixes are opposites and the instinct usually picks the wrong one.

What I like about the handbook, beyond the frameworks, is the through-line I keep meeting everywhere this year: the cheap things, building, polish, attention got cheaper (for more on this, read this small book) and the expensive things, judgment about what to cut, a checkable point of view, a customer’s costly commitment, the discipline to read a number instead of a feeling, got scarcer. IBR’s own tagline says it better than I can: judgment is scarce, execution is abundant.

Which is a strategy handbook’s way of saying what my last four articles said about AI. Nice to know the founders and the models are learning the same lesson.

-Hardik

I’ve spent about two decades building data and AI systems, and enough time around P&Ls to have watched good businesses cut themselves into the ground while calling it discipline. This closes my four-part walk through IBR’s handbook. If it was useful, the original is free at ikanabusinessreview.com and worth your subscription; and if you missed Parts 1–3, they’re the launch, the distribution, and the signal you’ll need before this one applies. Subscribe here too, obviously; my contribution factor per reader is positive and I’m merely sub-scale.

Series map: Part 1 · The Inverted Launch → Part 2 · The Founder Is the Channel → Part 3 · The Signal Cost Principle → Part 4 · The Contribution Factor (this).

Source: Ikana Business Review, Mini Strategy Handbook for AI Founders (August 2026), Review 04, “The Contribution Factor” by Vivek Bisht, including the formula, the decision table, and the Treya Gifts case (+180% orders, 33% contribution factor held, +8% fixed costs, loss to profit in twelve weeks); full case at ikanabusinessreview.com. The “responsible” argument, the AI-startup variable-cost translation, and the falling-token-price wrinkle are mine.

Can One Developer Beat Big Tech? Sideways, Yes.

Sat, 17 Oct 2026 01:56:50 +0000

Let me start with a confession. Bitly's cheapest plan with a custom domain was listed at around $29 a month. I looked at my wallet. My wallet looked back with concern.

So I did what any reasonable developer does when the price is too high: I built my own. That's how Fewly was born.

"Compete with the tech giants" sounds like a movie trailer, I know. One guy, one laptop, one dream, and 47 open browser tabs. But stay with me, because the trick is not what you think.

You don't fight giants. You find the gap.

Big companies are cargo ships. Huge, powerful, and very busy chasing enterprise contracts. Freelancers, students and small creators are not on their radar, so the pricing slowly drifts toward whoever owns a corporate card.

I'm a speedboat. I can't carry 10,000 containers, but I can park in the small harbor nobody else bothers with.

Cuttly is kinder than Bitly, with paid plans from about $12 a month. Prices change, so check them yourself. The point is that the gap I found was not a missing feature. It was a missing price.

So what does Fewly do?

Paste a long URL, get a short one. No account needed. Then it gets more interesting:

Free: 50 links a month, 30 days of analytics, basic QR codes.
Pro, $5 a month: unlimited links, branded domains, 1 year of analytics, API.
Team, $9 per seat: workspaces, roles and an audit log.

Honest note: branded domains are a Pro feature, not free. But branded short links at $5 instead of $29 is a conversation a freelancer can actually have.

The blockers (aka the fun part)

Blocker 1: My first QR generator was embarrassing. It made a QR code for a link. That's it. A QR generator that only does links is a Swiss Army knife with one blade, which is just a knife. So I added WiFi, WhatsApp, vCard, email, SMS, location, social and payment codes.

Blocker 2: DNS. Custom domains need DNS records, and DNS is the one place on the internet where everyone is equally confused. So now Fewly shows you the exact records to add, verifies them, and sets up HTTPS on its own. Fewer tears all around.

Blocker 3: People will shorten sketchy stuff. Of course they will. So every link is scanned for malware and phishing, and anything pointing to private or internal addresses gets refused. Turns out a link shortener also has to be a bouncer.

Then I got carried away and built tools

Fewly now has 73 free browser tools. No signup, no uploads, no watermarks. Everything runs on your own device, which also keeps my server bill small. That's the only reason "free" survives.

My favorites:

Online DB Viewer. Drop in a SQLite file, browse tables and run real SQL with the online DB viewer. The file never leaves your machine. Perfect for that moment when you pull a database out of an app and wonder what's inside.
Text to Handwriting. The text to handwriting tool turns typed text into ruled notebook pages. To be clear, it's a handwriting font, not a clone of your own writing. Use it for worksheets and cards, not for crimes.
QR Code Generator. A free QR code generator with PNG and SVG download. No signup, no watermark, and yes, it does more than links now.
Payment Fee Calculator. On a $5 sale, Stripe's $0.30 fixed fee eats nearly 9%. The payment fee calculator shows what actually lands in your account. Want to receive exactly $500? Charge $515.24, not $514.50. Math is sneaky like that.

What I learned

1. Hunt for gaps in price, privacy and speed. Features are easy to copy. A fair price is harder.

2. Free tools are a front door. Someone comes for a JSON formatter, leaves in ten seconds, and now knows my name.

3. Be honest. Bitly has a name everyone knows, years of trust and enterprise clients. Fewly is young. I'm not claiming a win. I'm saying one small corner of the market was underserved.

So, can a solo dev still compete?

Not head on. Sideways, absolutely.

Try Fewly and tell me what's missing. I read every message, mostly because I'm the only one here.

At Seed Stage You Don’t Have a Brand. You Have a Person. (Bad News for People Who’d Rather Build.)

Wed, 14 Oct 2026 12:33:15 +0000

Part 2 of 4 on IBR’s Mini Strategy Handbook for AI Founders. This is the review about distribution, and I’m going to write it the way it tells me to: with the scar showing.

In Part 1 I confessed to shipping eight products this year and being much better at the launching than the cutting. Here’s the second, worse confession, the one that makes Ikana’s Review 02 read like it was addressed to me personally: I can ship anything, and I struggle to distribute it. My own operating rules literally include “outbound is oxygen,” which is the kind of rule you write when you have been, historically, holding your breath.

So Richa Sati’s The Founder Is the Channel is uncomfortable reading, and therefore probably correct. The core claim: at seed stage you don’t have a brand. You have a person. Distribution starts with that person being specific in public, repeatedly, about a problem they’ve actually bled over. Not with ad spend. Not with a logo. With a scar.

The polish inversion
The mechanism underneath is the sharpest idea in the whole handbook, and it rhymes with things I’ve written about AI deflation. For twenty years, professional-looking content was a moat: a design agency and a copywriter meant you looked credible; without them you looked like a hobby. AI made polished content free, instant, and identical, everyone drawing from the same tools. So polish stopped signaling competence and started signaling nothing, and in some rooms it now signals inauthenticity: if your About page reads like GPT wrote it, and it probably did, the thing that used to build trust quietly erodes it.

Cheap production didn’t democratize credibility. It devalued the currency credibility used to trade in. And what’s still scarce, still expensive to fake? The handbook’s phrase: a specific human with a specific scar, saying something a committee would never approve.

Read that with the deflation lens from my last few pieces and it clicks: polish is a capability, capabilities got free, and the premium migrated to the one thing you can’t pip install, a person with a checkable track record. Same pattern, different arena.

The Swap-the-Logo Test
Then comes the tool I’ve already started running on my own drafts, and it stings. Take your last post. Paste it onto a competitor’s account. Does it still make sense? Then you haven’t written anything. You’ve assembled category filler.

The handbook’s contrast is Pieter Levels, no investors, no PR, just years of building in public with the actual revenue, the actual failures, the actual 3 a.m. decisions, versus the median AI startup account: a rotating cast of “excited to announce,” dashboards nobody outside can verify, enthusiasm calibrated to offend no one. Not wrong. Just interchangeable.

The distinction I found most useful is that this is a Ben Thompson problem, not a GaryVee problem. “Just be authentic” mostly produces founders performing authenticity, which is its own noise. What actually moves markets is a specific, arguable, falsifiable point of view, delivered consistently, so people know exactly what you think and can check your track record against it. The mechanism isn’t charisma. It’s legibility of belief. “AI will change everything” can’t be checked against anything. “Trust is the last scarce thing in AI, and here’s why” can, and if I’m wrong you’ll get to say so.

The SCAR test
The review’s operational tool is four questions that are secretly one question, could literally any other founder in your category have written this?

Scar, not slogan: “we democratize AI” versus “I hand-labeled data for four months and wanted to set myself on fire.” Contrarian, not consensus: would a smart peer have real reason to disagree? Artifact, not announcement: show the eval, the ticket, the graph of what broke; announcements decay in hours, artifacts get cited for months. Repeated, not one-off: Nomad List wasn’t one good post, it was years of them.

The Stripe example lands the point: the Collisons wrote deeply technical posts that only made sense if you’d hit the exact walls they described. Nobody hires an agency to fake that level of specificity, because faking it costs more than having the scar. Hence the line I’d frame: the scar is the moat, the one thing a better-funded fast-follower can’t clone by Tuesday.

Where it breaks, and the honest bit
Credit to the review for saying where the mechanism fails, because most “build in public” gospel doesn’t. Regulated and enterprise infrastructure: a hospital procurement officer does not care about your Twitter. At scale, structurally: multiple product lines and a sales org eventually need a brand that doesn’t live or die on one person’s posting cadence. And when it’s performed instead of lived: people detect a staged “day in the life” even when they can’t articulate why.

That first exception matters for me specifically, because half my portfolio sells into enterprises and clinics, where the buyer wants institutional trust, not my feed. So the honest synthesis is: the founder channel is how you get the first believers and the first ten customers, and it is not how you get the hospital. Both are true. Plan for both and don’t run into the same ‘build before sell’ hole as articulated in Part-1 of the series.

What I’m actually going to do
Since the review demands specificity, here’s mine. My scar isn’t “passionate about AI.” It’s: two decades building data systems, a year of shipping products faster than I could sell them, and the slow, expensive realization that the launch was never the constraint. That’s a checkable, slightly embarrassing, entirely mine sentence, and it passes the swap-the-logo test, because no competitor would want to paste it.

The Part 1 caveat comes due here: launching wide divides your voice by the number of tools. The Founder-Is-the-Channel model only works with one identity, repeated. My own rule says one identity for twelve months. I wrote the rule. Time to obey it.

Next, Part 3, on the trap that catches you after distribution starts working: mistaking loud signals for real ones. The handbook has a ladder. Bring your waitlist. We’ll see where it sits.

-Hardik

I’ve spent about two decades building data and AI systems, and one uncomfortable year learning that “outbound is oxygen” is easier to write on a wall than to breathe. This is Part 2 of 4 on IBR’s handbook. Part 3, The Signal Cost Principle, is the framework I wish I’d had before my first “we broke the site” screenshot. Subscribe; the scar tissue economy pays out slowly, but it does pay.

Series map: Part 1 · The Inverted Launch → Part 2 · The Founder Is the Channel (this) → Part 3 · The Signal Cost Principle → Part 4 · The Contribution Factor.

Source: Ikana Business Review, Mini Strategy Handbook for AI Founders (August 2026), Review 02, “The Founder Is the Channel” by Richa Sati, including the polish inversion, the Swap-the-Logo Test, and the SCAR test; the full argument is at ikanabusinessreview.com. The confessions and the deflation framing are mine.

Top Digital Product Delivery Platforms for Selling eBooks and Courses

Thu, 24 Sep 2026 16:40:08 +0000

Selling an eBook or online course no longer requires building a complete ecommerce system from scratch. Digital product delivery platforms now combine storefronts, checkout, file delivery, course hosting, payment processing, customer management, analytics, and, in some cases, affiliate tracking and marketing tools.

The important distinction is that these platforms are not interchangeable. Some are designed primarily for downloadable products. Others are built around structured online learning. Some charge monthly subscriptions, while others take a percentage of each transaction. For publishers and creators using affiliate marketing, paid traffic, sponsored content, or other acquisition channels, tracking and attribution can be just as important as the checkout itself.

The following platforms are worth considering when the objective is to sell eBooks, courses, or both.

Payhip
Payhip is built around digital commerce and supports a wide range of products without requiring sellers to build their own ecommerce infrastructure.

Its pricing structure is straightforward. The Free Forever plan has no monthly subscription but charges a 5% transaction fee. The Plus plan costs $29 per month with a 2% transaction fee, while the Pro plan costs $99 per month with no Payhip transaction fee. Payment processors such as Stripe and PayPal still charge their own fees. Payhip states that all three plans provide access to all features, unlimited products, and unlimited revenue.

For an eBook publisher, the main attraction is the low barrier to entry. A creator can begin without committing to a monthly subscription and move to a paid plan as sales increase.

Payhip also has built-in affiliate functionality. Sellers can create affiliate programs, assign products to affiliates, generate unique tracking links, and establish commission rates. Payhip reports a 30-day cookie duration, with commissions attributed to the last touchpoint before conversion. However, sellers are responsible for paying their affiliates themselves. Payhip provides monthly affiliate sales reports rather than automatically distributing those commissions.

That makes Payhip particularly relevant to publishers who want to combine direct sales with an affiliate network without adding separate affiliate software.

Gumroad
Gumroad has become a prominent option for creators selling digital products directly to an audience.

The platform supports eBooks, courses, memberships, subscriptions, digital downloads, and other digital products. Gumroad also allows creators to use its storefront or embed purchasing functionality into an existing website.

Its commercial model differs substantially from subscription-based platforms. Gumroad currently charges 10% plus $0.50 per transaction for sales made through a creator's direct Gumroad presence, in addition to applicable sales tax and payment processing charges. Sales generated through Gumroad's Discover marketplace are subject to a 30% fee that includes processing. Gumroad does not charge a monthly subscription fee.

For creators who are testing an eBook or course idea, this model removes the recurring platform bill. The tradeoff is that transaction costs can become significant as sales volume grows.

Gumroad also supports affiliate selling. Creators can add affiliates, while Gumroad's Discover products can be promoted through its affiliate system. Affiliate links use tracking mechanisms to attribute purchases. Gumroad states that Discover affiliate links have a seven-day cookie window, while links provided directly by creators to their affiliates use a 30-day cookie window.

This makes Gumroad relevant to publishers whose acquisition strategy includes bloggers, newsletter operators, creators, or other partners.

Podia
Podia takes a broader approach by combining digital product sales with online courses, memberships, coaching, community products, and email marketing capabilities.

Podia allows creators to create paid offers for online courses, downloads, coaching products, bundles, and other products. Its pricing system supports one-time payments, payment plans, and recurring subscriptions.

That combination is useful when an eBook is only one component of a larger business. For example, a creator could sell an eBook as a standalone product and also offer a course or membership built around the same subject.

Podia's transaction structure depends on the plan. As of 2026, the company's Mover plan carries a 5% transaction fee, while the Shaker and Earthquaker plans remove Podia's transaction fee and provide additional capabilities. Payment processor charges from Stripe or PayPal remain separate.

Affiliate functionality is also available. Podia's affiliate program allows sellers to establish default and product-specific commission rates, invite affiliates, and use unique referral links. The affiliate system uses cookies to attribute sales, and Podia provides affiliate reporting covering clicks, referrals, sales, and related activity. The affiliate feature is available on Shaker and Earthquaker plans.

For a creator building a business around multiple product types, Podia provides a more consolidated environment than a basic file-delivery service.

Teachable
Teachable is primarily associated with online courses, but it also supports digital downloads, making it suitable for creators who want to sell both educational programs and downloadable publications.

Teachable's digital download system supports eBooks, guides, audio files, podcasts, printables, and other downloadable material. Downloads can be sold as standalone products or incorporated into broader offers such as bundles and order bumps.

The platform also supports several pricing models for courses, including one-time purchases, payment plans, and subscriptions. Digital downloads have more limited pricing options, including free products, one-time payments, and payment plans.

Teachable's current plan structure includes Starter, Builder, Growth, and Advanced. Its published pricing shows Starter at $39 per month when billed monthly or $29 per month when billed annually. Builder is $89 monthly or $69 annually, Growth is $189 monthly or $139 annually, and Advanced is $399 monthly or $309 annually.

Transaction fees also vary by plan. Teachable currently lists a 7.5% transaction fee on Starter and 0% on Builder, Growth, and Advanced, before payment processing charges.

Teachable therefore makes more sense for creators whose primary commercial product is an online course and who want eBooks or other downloads to support that course business.

Thinkific
Thinkific is another course-focused platform that has expanded beyond conventional course hosting.

Its current Basic plan is listed at $54 per month when billed monthly or $40 per month when billed annually. The Start plan is $109 monthly or $82 annually, while Grow is $219 monthly or $164 annually. Thinkific's 2026 pricing update took effect from August 13, 2026, increasing the listed Basic, Start, and Grow prices by approximately 10%.

Thinkific's Basic plan includes unlimited courses and supports digital products, including up to five eBooks, workbooks, or templates. Higher plans expand the digital download capability. The platform also supports checkout features such as order bumps, coupons, gifting, payment plans, memberships, subscriptions, and product bundles.

For publishers concerned with affiliate attribution, Thinkific includes affiliate reporting among its sales tools. Its platform can track affiliate sales and commissions, which makes it more relevant to a course business using partner-driven customer acquisition.

Thinkific does not offer a permanent free plan, although it currently provides a 30-day free trial. The company also states that it does not take a commission from course sales, although payment processing and applicable third-party fees can still apply.

Sellfy
Sellfy is designed for creators who want a storefront for digital products without building the entire ecommerce system themselves.

Sellfy supports digital downloads, subscriptions, merchandise, and physical products. Its current published pricing lists Starter at $22 per month, Business at $59 per month, and Premium at $119 per month, with annual billing available at discounted rates. Sellfy states that its plans do not charge additional transaction fees, although payment processors such as Stripe and PayPal charge their own fees.

The platform also provides email marketing and other commerce functions. Business and Premium plans add features including product upselling, cart abandonment tools, and affiliate marketing.

Sellfy's built-in affiliate system allows sellers to configure commission rates, manage partners, and track affiliate activity. Its affiliate documentation identifies partner-link tracking, minimum payout settings, and product commission rates as core configuration options. The affiliate feature is available to Business, Premium, and Custom plan users.

For a creator selling eBooks alongside other digital products, Sellfy provides a storefront-oriented alternative to course-first platforms such as Teachable and Thinkific.

What matters when choosing a digital product platform?
The platform's headline feature list should not be the only consideration. The economics of the business matter more.

Transaction fees
A platform with no monthly fee can still become expensive if it takes a substantial percentage from every sale. Conversely, a monthly subscription can become more economical at higher sales volumes.

For example, Gumroad's direct-sale fee is currently 10% plus $0.50 per transaction, while Payhip's free plan charges 5%. Teachable uses a subscription model with plan-dependent transaction fees, and Thinkific does not charge a commission on course sales.

Creators should calculate the total cost using their actual expected sales volume rather than comparing subscription prices alone.

Affiliate tracking
Affiliate marketing introduces another technical requirement. A platform needs to identify which partner generated a sale and calculate the associated commission correctly.

Payhip uses unique affiliate keys and a 30-day cookie window. Gumroad uses different cookie windows depending on the affiliate arrangement. Podia supports configurable affiliate commissions and attribution settings. Sellfy provides partner-link tracking and commission management.

These details matter when a publisher plans to rely on affiliates, review websites, newsletters, influencers, or other third-party traffic sources.

Product type
An eBook business does not necessarily need a full learning management system. A course business usually requires more than simple file delivery.

Payhip, Gumroad, and Sellfy are particularly oriented toward digital commerce and downloadable products. Teachable and Thinkific place greater emphasis on structured online learning. Podia occupies a broader position by combining courses, downloads, memberships, coaching, and community products.

Marketing and analytics
Selling the product is only one part of digital commerce. Publishers also need to understand where customers originate, which products convert, and which promotional channels generate revenue.

Features such as abandoned-cart recovery, affiliate reports, customer analytics, email tools, coupons, order bumps, and product bundles can reduce the need for separate software.

For publishers buying advertising or sponsored placements, this distinction becomes important. The acquisition cost of a customer should be measured against the actual revenue generated after platform fees, payment processing, affiliate commissions, refunds, and advertising costs.

Which platform fits which business model?
For a creator starting with downloadable eBooks and looking to minimize fixed costs, Payhip or Gumroad provide straightforward entry points. Payhip offers a free plan with a transaction fee, while Gumroad operates without a monthly subscription but charges a higher transaction fee on direct sales.

For a business combining eBooks, courses, memberships, and community products, Podia provides a broader product mix in one platform. Its affiliate tools are also directly integrated into the seller dashboard.

For a business where the course is the main product and the eBook functions as a companion product, lead magnet, or additional offer, Teachable or Thinkific provide stronger course-oriented infrastructure. Both support digital downloads alongside course products.

For creators who want a storefront covering digital products and potentially physical merchandise, Sellfy provides a commerce-focused alternative with built-in email marketing and affiliate capabilities on eligible plans.

Final considerations
The best platform is determined by the economics and technical requirements of the business, not by the size of a platform's feature list.

An eBook seller should examine transaction fees, payment processing, file delivery, tax handling, affiliate attribution, analytics, customer ownership, and the ability to export customer data. A course creator should add lesson delivery, student management, quizzes, certificates, memberships, payment plans, and learning analytics to that evaluation.

Affiliate marketing also deserves careful attention. A platform that can track partner referrals inside the same system can eliminate the need for additional affiliate software, but commission rates, attribution windows, payout procedures, and plan restrictions must be examined before launching a program.

The six platforms covered here represent different approaches to the same commercial problem. Payhip and Gumroad emphasize accessible digital commerce. Podia combines several creator-business functions. Teachable and Thinkific place online education at the center. Sellfy focuses on creator commerce and storefront functionality.

Before committing, calculate the expected monthly sales, average order value, affiliate commissions, payment-processing costs, advertising expenditure, and platform fees. Then compare the resulting net revenue rather than comparing subscription prices in isolation. Platform pricing and features can change, so the provider's current pricing and documentation should be checked before making a purchasing decision.

Ecommerce SEO Audit Checklist

Tue, 01 Sep 2026 15:50:00 +0000

Direct answer: start by defining the URLs that should be indexed, then crawl the paths customers and bots can follow. Control filters and parameters, and reconcile redirects, canonicals, internal links, and sitemaps. Next, inspect category and product templates, Product and variant data, and stock states. Finally, compare the cleaned inventory with Search Console. Fix discovery and canonical conflicts before rewriting page copy or chasing rich-result warnings.

This checklist diagnoses a store-wide URL and template system. It does not teach product or category copy in depth, replace a migration plan, or repeat every crawler setting. Use the technical SEO audit workflow when you need the full crawl and Search Console evidence process.

Jump to verification checklist →

Use this audit map

Area	Evidence to collect	Pass condition
Indexable inventory	Template list, URL samples, XML sitemap	Every intended category and product has one preferred URL
Discovery	Navigation crawl, orphan report, pagination paths	Important pages are reachable through crawlable links
Filters and parameters	Parameter patterns, combinations, crawl volume	Useful landing pages are distinct; unwanted combinations do not expand the crawl
Canonical signals	Status, redirect, canonical, internal links, sitemap membership	Signals consistently point to the same preferred URL
Templates	HTML, rendered output, mobile output, structured data	Primary content and signals survive every representative template
Measurement	Search Console pages, queries, indexing groups	Issues are prioritized by affected templates and search evidence

1. Define the indexable store inventory

List the page types the store intentionally wants in search before opening a crawler. Typical candidates include the homepage, departments, categories, useful subcategories, product detail pages, editorial guides, store locations, and selected campaign pages. Account, cart, checkout, internal search, sorting, session, and tracking URLs normally serve users or operations without needing a separate search result.

Do not decide by URL shape alone. A filtered collection can deserve indexing when it serves a stable demand with unique inventory and useful context. The same filter can be wasteful when it creates a thin duplicate or an empty combination. Record the business owner, intended canonical, indexability, sitemap state, and one real example for every template.

Template	Example URL	Index?	Canonical target	Sitemap?	Owner
Category	`/ceramics/`	Yes	Self	Yes	Merchandising
Product	`/ceramics/blue-vase/`	Yes	Self	Yes	Catalog
Filter	`/ceramics/?color=blue`	No	Policy decision	No	SEO
Search	`/search?q=blue`	No	None	No	Product

2. Crawl the paths shoppers and Google can follow

Run a normal crawl from the preferred origin with robots rules respected. Then compare it with XML sitemap URLs, Search Console landing pages, analytics landing pages if available, product feeds, and the commerce platform export. The differences matter more than a single crawl total.

Google says it uses page relationships to understand ecommerce structure and recommends linking categories, subcategories, and products with crawlable <a href> links. Googlebot generally does not submit a site search form, so search-only products may remain undiscovered. A sitemap or Merchant Center feed can supplement discovery, but neither repairs a weak internal path. See Google's guidance on helping Google understand an ecommerce site structure.

Protect the store while crawling. Exclude checkout, accounts, carts, wish lists, internal search, and unbounded parameter spaces. Use a considerate crawl rate and test against a small sample before expanding.

Investigate four gaps:

important URLs in the catalog but not in the crawl;
crawlable URLs missing from the intended inventory;
sitemap URLs that redirect or canonicalize elsewhere;
Google landing pages that no current navigation path reaches.

3. Decide what happens to faceted and parameter URLs

Group parameters by function: filtering, sorting, pagination, tracking, session state, display mode, and campaign attribution. Sample real combinations and count how quickly each family expands. A five-filter interface can create far more URLs than products.

Google's current faceted navigation guidance warns that generated combinations can consume large amounts of crawling. When faceted URLs are not needed in search, prevent the unwanted crawl through an enforceable URL and robots policy. When a subset should be indexable, keep parameter order stable and return a real 404 for empty or nonsensical combinations. Give each selected landing page consistent internal links, content, canonical signals, and sitemap treatment.

Pattern	Default audit decision	Reason to make an exception
Sort order	Do not index	Rarely creates a distinct search job
Tracking and session	Do not index	No separate content value
Single useful attribute	Evaluate	Stable demand, enough inventory, useful landing-page context
Multiple arbitrary filters	Usually do not crawl or index	Only when intentionally curated as a durable collection
Empty combination	404	None when no matching inventory exists

Do not use one blanket canonical to the unfiltered category as a substitute for controlling an infinite crawl. Canonical is a consolidation signal, not a crawl-budget switch. For the implementation sequence behind filter combinations, pagination, empty states, and crawlable internal discovery, continue with faceted navigation and pagination for ecommerce SEO.

4. Test pagination and category discovery

Open a deep category with JavaScript disabled and inspect the source links. Each paginated URL should have a unique, crawlable address, and products beyond the first viewport should still be discoverable. Infinite scroll and load-more interfaces need an underlying sequence of URLs and links that a crawler can follow without clicking or scrolling.

Google's pagination guidance for ecommerce explains that crawlers may not trigger user interactions. Test first, middle, and final pages for self-canonicals, status codes, duplicate metadata, empty states, and products that disappear when inventory changes.

Do not canonicalize every paginated page to page one when later pages contain distinct products. Also verify that removing or adding a product does not leave an endless chain of empty pages.

5. Align redirects, canonicals, links, and sitemaps

For every representative URL, compare the requested URL, final status, redirect target, HTML canonical, internal-link destination, sitemap URL, and any locale or variant signals. The preferred version should be the version the site actually links to and submits.

Google treats redirects and rel="canonical" as strong canonicalization signals, while sitemap inclusion is weaker. Signals can reinforce each other when they agree. Review Google's duplicate URL consolidation guidance, then use the sitemap and non-canonical URL fix for implementation detail.

Protocol and host: HTTP, HTTPS, www, and non-www should resolve consistently.
Path variants: casing, trailing slashes, duplicate category paths, and legacy handles need one policy.
Parameters: internal navigation should not add tracking or display parameters to canonical product links.
Sitemaps: include absolute, preferred, indexable URLs that return a successful response.

6. Inspect product templates, variants, and stock states

Sample products by revenue, category, inventory state, number of variants, age, and traffic. Include a simple product, a multi-variant product, an out-of-stock item, a discontinued item, a product with reviews, and a newly created item. Inspect initial HTML, rendered DOM, mobile output, status, canonical, links, title, primary heading, price, availability, media, and purchase state.

Choose variant URLs deliberately. In a single-page model, each variant should be directly preselectable through a distinct stable URL state while the overall ProductGroup keeps one canonical product URL. Separate variant pages can work when users search for the variation and each page remains stable, internally linked, and accurately represented. Avoid a hybrid where feeds, internal links, canonicals, and structured data disagree about whether variants are separate products.

Stock state	Audit question	Typical safe route
Temporarily unavailable	Will the same product return?	Keep the useful page, show accurate availability, preserve alternatives
Permanently discontinued with replacement	Is there a close successor?	Redirect only when the replacement satisfies the same user job
Permanently discontinued without replacement	Does the page still help users?	Keep useful reference content or return 404/410 when it has no remaining value
Deleted by mistake	Should the catalog item still exist?	Restore the original URL and repair feed or inventory synchronization

Do not redirect every removed product to its category. A misleading redirect hides the missing item without giving the user an equivalent result.

7. Check structured data against the visible offer

Validate Product markup on representative product pages, not category templates. Compare every property with the visible page and current offer: name, image, price, currency, availability, condition, seller, ratings, and reviews. Google notes that Product markup can support product snippets or merchant listing experiences, and variants can be represented with ProductGroup and Product. Read the official Product structured data documentation and product variant documentation.

A valid Rich Results Test is not the end of the audit. Confirm that the server or rendered page exposes the same current price and stock state users see. Google cautions that rapidly changing price and availability produced only through JavaScript can be less reliable for crawling. Also reconcile website markup with merchant feeds so the same offer does not publish conflicting values.

Markup describes the specific product page, not a category of many unrelated products.
Variant and group identifiers are stable and consistent with canonical decisions.
Ratings and reviews are visible, attributable, and about the marked-up product.
Currency, price, and availability match the purchasable offer.
Validation warnings are prioritized by eligibility and data accuracy, not by count alone.

8. Prioritize with Search Console and template reach

Join the cleaned inventory with Search Console performance and indexing evidence. Use normalized URL keys, but preserve raw URLs so canonical aggregation and parameter behavior remain inspectable. Segment by template, category, indexability decision, status, canonical target, sitemap state, and issue type.

Real FloxoLab Search Console Page indexing snapshot. The counts and validation states are property-specific; use the issue groups to choose what to inspect, not as universal targets.

Prioritize a defect when it affects an intended template at scale, blocks discovery or consolidation, contradicts the store's inventory policy, or is tied to meaningful impressions, clicks, revenue, or strategic products. A warning on one obsolete URL is not automatically more urgent than a navigation defect hiding thousands of products.

Once the technical inventory is stable, use the product and category page SEO guide to implement useful store templates, variants, availability, media, links, and Product data. Use the on-page SEO audit checklist for the wider page-level review.

What not to do

Do not crawl every filter combination by default. Scope and sample the parameter space first.
Do not submit every platform-generated URL. Sitemaps should reinforce the preferred inventory.
Do not canonicalize conflicts without fixing internal links. Users and crawlers should receive the preferred URL directly.
Do not treat every excluded URL as an error. Carts, searches, duplicates, and controlled facets may be intentionally excluded.
Do not remove out-of-stock pages automatically. Decide from permanence, replacement fit, links, demand, and remaining user value.
Do not add Product markup to a category just to increase schema coverage. Mark up the actual eligible product offer.
Do not rewrite thousands of descriptions before fixing discovery and canonical conflicts. Repair the system that determines which pages can compete.

Verification checklist

Every store template has an explicit indexability and canonical policy.
Important categories and products are reachable through crawlable links.
Search forms, filters, sorting, tracking, and sessions do not create an uncontrolled crawl space.
Pagination exposes stable URLs and links to products beyond the first page.
Redirects, canonicals, internal links, feeds, and sitemaps agree on preferred URLs.
Representative product and category templates return complete mobile and desktop output.
Variant URLs and ProductGroup relationships match the store's actual selection model.
Price, currency, availability, ratings, and reviews match the visible offer.
Temporary and permanent stock states have separate, documented handling.
Search Console evidence is segmented by template and compared with the intended inventory.
Fixes are ranked by template reach, search evidence, user harm, and commercial importance.

An ecommerce audit is complete when the store can explain which URLs should exist, how crawlers reach them, which version cons

Product and Category Page SEO

Sat, 29 Aug 2026 03:50:01 +0000

Direct answer: make a category page help shoppers narrow a meaningful product set, then make each product page answer whether the specific item fits, what it includes, what it costs, whether it is available, and what happens next. Link the hierarchy with crawlable anchors, choose one deliberate variant URL model, expose useful media in standard HTML, and make Product data match the visible offer.

This guide implements product and category templates. It does not repeat the sitewide crawl, faceted-navigation, canonical, sitemap, or Search Console diagnosis in the ecommerce SEO audit checklist. Stabilize that inventory first when the store does not yet know which URLs should be indexed. Then use the faceted navigation and pagination guide to control filter combinations and later product pages.

Jump to the verification checklist →

Use this page-job map

Page type	Primary job	Evidence the page needs
Category	Help a shopper understand and narrow a product set	Scope, useful groupings, visible inventory, filters, comparison cues, crawlable product links
Product	Help a shopper evaluate one product or deliberate variant group	Identity, media, options, price, availability, specifications, delivery, returns, trust, related routes
Variant	Represent a meaningful option without creating accidental duplicates	Stable selection state, unique identifiers, consistent URL and canonical model, accurate offer data

1. Assign one job to each template

Start with a representative department, one category, one simple product, and one multi-variant product. Write the user question each page must answer. A category might answer “Which office chairs fit a small room?” A product might answer “Will this chair fit my desk, budget, delivery window, and return requirements?”

Do not make a category imitate a product page or make a product page repeat every category introduction. Shared brand, shipping, and policy details can appear where useful, but the distinctive evidence should belong to the page that owns the decision.

Keep the preferred URL stable. Google says it generally understands ecommerce structure from page linkages rather than inferring hierarchy from URL folders. Clean paths are useful to people and operations, but internal navigation still has to express the relationship. See Google's current guidance on ecommerce navigation structure and ecommerce URL design.

2. Build category pages for discovery and comparison

A useful category page explains what belongs in the set, exposes the products, and gives shoppers enough information to narrow without opening every card. The exact controls depend on the inventory, but the template should support these jobs:

Orient: a descriptive title, primary heading, short scope, and clear subcategory routes.
Scan: recognizable product names, useful images, meaningful price or availability information, and one consistent product-card action.
Narrow: filters and sorting that match real buying decisions rather than every database field.
Compare: expose the attributes that distinguish products in this category, such as capacity, material, fit, compatible use, or delivery state.
Continue: crawlable links to every intended product, pagination route, adjacent category, and useful buying guidance.

Category copy does not need to bury the products under a long essay. Place the concise orientation before or near the inventory, then add supporting guidance where it genuinely answers a follow-up question. If every category inherits the same generic paragraph with only one noun replaced, the template has created duplication rather than usefulness.

Category pages are navigation surfaces first. A paragraph cannot compensate for products that appear only after a search form, interaction, or client-side event that produces no crawlable link.

3. Build product pages for confidence and action

A product page should identify the item quickly, then reduce the uncertainty that blocks the purchase or inquiry. Put the essentials near the primary action and keep deeper evidence easy to find.

Product element	Implementation test	Common failure
Name and product identity	Distinct, understandable without the breadcrumb	SKU-only or manufacturer string that shoppers cannot interpret
Price and availability	Visible, current, and tied to the selected option	Structured data, feed, and visible page disagree
Options	Selection changes the offer state and remains accessible	Color or size exists only as an unlabeled visual swatch
Media	Shows the product, scale, important details, and relevant variation	One decorative image or hidden CSS background
Specifications	Answers fit, compatibility, materials, dimensions, care, and included items	Important facts buried in an image or downloadable file
Delivery and returns	Important limits are visible before commitment	Generic promise that contradicts the product or destination

Use the language customers need to make the decision. A manufacturer description can supply facts, but copying it unchanged across resellers does not explain the store's own offer, delivery, selection help, or relevant limitations.

4. Connect categories, products, and supporting guides

Google recommends crawlable <a href> links from menus to categories, categories to subcategories, and subcategories to products. Googlebot generally does not submit search forms, so products discoverable only through internal search can be missed by normal crawling.

Link every intended category from a stable menu, department, or parent route.
Link every intended product through a crawlable category or subcategory sequence.
Keep pagination or incremental-loading URLs accessible without requiring a click or scroll event.
Link a product back to its most useful category, compatible items, replacements, care guides, and buying guidance.
Link editorial guides to relevant products only when the product is a logical next step.

Do not make every product link to every other product. Related links should express compatibility, substitution, next use, or a genuine comparison. The hierarchy becomes clearer when links reflect real relationships rather than a generic popularity widget.

5. Choose one variant URL model

Variants can share one product page through stable, directly preselected URL states or live on separate pages. Neither model is universally correct. The choice depends on whether each option has distinct demand, content, media, availability, identifiers, and a durable landing state.

Model	Use it when	Required consistency
One product page / single-page model	Options are selectable states of the same product decision	Each variant can be directly preselected with a stable URL state; the overall ProductGroup uses one canonical product URL
Separate variant URLs	A variant is independently searched, shared, stocked, or merchandised	Each URL loads the correct selection, uses stable identifiers, and follows one internal-link and canonical policy
Mixed accidental model	Never as a deliberate choice	Fix feeds, links, canonicals, parameters, and markup so they stop describing different URL models

Google's product variant documentation supports grouping variants with ProductGroup and individual Product entities. Treat markup as a description of the implemented model. Do not use it to hide URL or selection behavior that remains contradictory.

6. Handle availability without erasing useful pages

Temporary unavailability is different from permanent removal. Keep a useful product URL when the same item is expected to return, show the real availability, preserve specifications and support information, and offer a relevant notification or alternative route. Do not present an unavailable item as purchasable.

When a product is permanently discontinued, decide from remaining demand, inbound links, support value, and replacement fit. Redirect only when the replacement satisfies substantially the same job. Otherwise keep a useful reference page or return an honest 404 or 410 when no useful page remains. Redirecting every removed product to a category creates a misleading destination.

Update the visible page, Product data, merchant feed, internal recommendations, and sitemap policy together. A status badge changed in one system is not enough when another still advertises the item as in stock.

7. Make product media crawlable, useful, and fast

Use standard HTML image elements, descriptive alternative text where the image conveys information, explicit dimensions, responsive sources, a fallback src, and formats appropriate to the content. Google says it can find images in an img element, including inside picture, but not an image supplied only as a CSS background. Its current image SEO guidance also recommends responsive delivery and balancing quality with page weight.

Show the real product clearly before lifestyle or decorative images.
Include useful angles, scale, materials, controls, packaging, and included items when relevant.
Update media when a selected variant materially changes appearance.
Do not place product names, specifications, or care instructions only inside images.
Load the primary product image promptly; defer below-the-fold media when appropriate.

Use the mobile SEO checklist to confirm that galleries, selectors, tables, sticky actions, and supporting content remain usable on the smaller layout.

8. Match Product data to the visible offer

Add Product markup to a page about a specific product or deliberate variant group, not to a category containing unrelated products. Google's Product structured data introduction distinguishes product snippets from merchant listings and notes that supported search appearances can include price, availability, ratings, shipping, and return information. Eligibility does not guarantee a rich result.

For a page where customers can purchase, follow the current merchant listing requirements. Start with accurate identity and offer data, then add applicable properties the store can keep current:

product name, image, description, brand, and stable identifiers;
offer URL, active price, currency, availability, and condition;
shipping or return information when supported and accurate;
ratings and reviews only when visible and about the marked-up product;
variant grouping that matches the page and URL behavior.

Validate the markup, then compare it with the rendered page and merchant feed. The correct test is not merely “no critical errors.” It is “the marked-up offer is the offer a customer can actually select and buy.”

9. Release one representative template set

Select the sample. Use one category, one subcategory, a simple product, a variant group, an unavailable product, and a discontinued product.
Inspect initial and rendered output. Confirm titles, headings, canonical, links, content, media, selection state, Product data, and purchase state.
Test the crawl path. Start at the parent navigation and reach every sample product through ordinary anchors.
Test mobile interaction. Use real selector, gallery, filter, accordion, comparison, cart, and inquiry paths.
Compare systems. Reconcile the visible page, structured data, merchant feed, sitemap, inventory source, and Search Console inspection.
Expand only after the sample passes. Roll out the corrected template, then crawl the affected URL pattern and watch for new duplicates or missing products.

If a defect appears across every product or category, fix the shared source. The template-level technical SEO guide explains how to name the generator, owner, rollback path, and post-release test.

What not to do

Do not paste one long keyword paragraph above every product grid. Orient the shopper and expose the inventory.
Do not make products discoverable only through search or interaction. Build crawlable category and pagination paths.
Do not create a separate indexable URL for every selectable state by accident. Choose and enforce a variant model.
Do not canonicalize distinct useful products to a category. Consolidate only genuine duplicate or alternate URLs.
Do not mark up data customers cannot see or verify. Structured data must match the visible offer.
Do not delete temporarily unavailable products by default. Separate temporary stock state from permanent removal.
Do not hide specifications inside images or PDFs. Keep decision-critical facts in accessible HTML.
Do not publish a template change across the full catalog without a representative sample and rollback path.

Verification checklist

Each category has a distinct scope, useful inventory, and meaningful narrowing controls.
Each product page identifies the item and exposes price, availability, options, specifications, delivery, and returns as applicable.
Every intended product is reachable through crawlable category or pagination links.
Related links represent compatibility, substitution, support, or a real next decision.
The store uses one documented URL and canonical model for variants.
Temporarily unavailable and permanently removed products follow different rules.
Primary media uses standard HTML, useful alt text, dimensions, responsive sources, and a fallback URL.
Visible offer data, Product markup, merchant feed, inventory source, and selected variant agree.
Category pages do not use Product markup for a mixed inventory set.
Representative desktop and mobile templates pass before catalog-wide release.
A post-release crawl finds no new duplicate titles, conflicting canonicals, broken links, or orphan products.

The page templates are ready when a shopper can move from a meaningful category to a specific product decision, and the same relationship remains clear in links, URLs, media, offer data, and rendered HTML.

Evidence basis

Google's ecommerce navigation, URL structure, Product, merchant listing, product variant, and image guidance were checked from official documentation on August 23, 2026. The page-job map, template sample, release sequence, and availability decisions are FloxoLab implementation frameworks, not Google ranking factors or guarantees.

Google Sea

SaaS Analytics and Product Intelligence for Data-Driven Growth

Thu, 11 Jun 2026 12:29:38 +0000

Quick Overview

SaaS analytics transforms scattered product data into usable insights
for retention, revenue, and roadmap decisions.
Product intelligence links user behavior to business results through
event tracking and cohort analysis.
The right analytics stack lowers churn by identifying friction points
before they affect revenue.
Real-time dashboards help teams shift from reactive reporting to
proactive product decisions.
Choosing tools that work with your current dev workflow saves
engineering time in the long run.

Have you ever launched a feature, waited several weeks for results, and still been unable to determine whether it was effective? You are not alone. Most SaaS teams possess extensive user data but lack the appropriate systems to convert that data into actionable decisions. Dashboards exist; however, they are frequently disconnected, outdated, or fail to address the pertinent questions.

Product intelligence is crucial, not for collecting more data but for linking existing data to key questions. Why do users disengage after onboarding? Which features support retention? Where does your team focus on seldom-used features? Let's explore modern SaaS analytics, what makes a valuable product intelligence stack, and how teams use these insights to grow without guessing.

Why SaaS Analytics Is the Backbone of Product Decisions

SaaS analytics tracks user engagement from sign-up to cancellation, including event monitoring, funnel analysis, cohort behavior, feature adoption, and revenue. Effective analytics focus on context—like whether increased active users perform key actions or if changes in session length reflect disengagement or improved efficiency. Combining behavioral data with business context helps teams interpret signals accurately instead of reacting to distractions.

Many growing companies work with a SaaS development agency to set up this layer correctly from the beginning. Retrofitting analytics into an established codebase is much harder than planning for it from day one. Proper instrumentation, event classification, and data pipeline setup lay the groundwork for every insight that follows.

This is also where teams begin to recognize how choices regarding data infrastructure have broader effects. A product built with clear, well-documented event schemas not only produces better reports but also speeds up every future integration, A/B test, or customer segmentation effort.

How Product Intelligence Connects Data to Decisions

Product intelligence takes raw analytics data and adds the "why" behind user behavior. While analytics tells you what happened, such as when a user clicked a button, completed a workflow, or abandoned a session, product intelligence explains why it happened and what to do next.

This usually involves several key components working together:

Event tracking and tagging: Every important user action gets logged
with context, including timestamp, user segment, device, and session
details. Without consistent tagging rules, it becomes nearly
impossible to analyze this data at scale.
Cohort and segmentation analysis: Grouping users by signup date,
plan tier, acquisition channel, or behavior pattern reveals trends
hidden in the aggregated data. A feature might be very popular with
enterprise users but ignored by free-tier accounts, and that
difference is important for prioritizing efforts.
Funnel and retention curves: Mapping the path from trial to paid
conversion, or from first login to regular use, shows exactly where
users encounter obstacles. These drop-off points are often where
product teams find the most effective areas for improvement.
Feature adoption tracking: Understanding which features get used
regularly and which remain unused helps teams avoid the mistake of
building more without removing what doesn’t work.

When these components connect through a unified data layer rather than being scattered across different tools, teams stop debating opinions in meetings and start looking at evidence.

Building an Analytics Stack That Doesn't Slow Down Your Team

A common mistake is adding analytics tools to a product after it launches. This often leads to more technical debt than valuable insights. Engineering teams end up managing multiple SDKs, duplicate event schemas, and different data definitions across departments.

A better approach starts with defining a shared event taxonomy before implementing any tools. This involves getting agreement from product, engineering, and growth teams on what qualifies as a "conversion," how to name user properties, and which events are critical versus optional. This initial agreement not only improves reporting accuracy, but it can also boost web development efficiency by reducing the back-and-forth between teams trying to solve mismatched data definitions later.

Most modern tech stacks rely on a customer data platform (CDP) to centralize event collection. This platform then feeds into analytics tools for dashboards and reporting, as well as operational tools for triggering emails, in-app messages, or sales alerts. This separation of collection and activation allows teams to avoid being tied to a single vendor's reporting limitations.

API-first analytics platforms have become the norm because they enable engineering teams to send data once and route it to any downstream tool. This approach eliminates the need to implement separate tracking code for each tool, reducing both implementation time and long-term maintenance.

Turning Insights Into Action: Real-World Applications

Data sitting in a dashboard doesn't grow a business. Here's how teams actually use these insights:

Reducing onboarding drop-off: By mapping the exact steps where new
users leave during setup, teams can find out if the issue is
confusion with the interface, lack of clear value, or technical
problems like slow loading times.
Prioritizing the roadmap with usage data: Instead of focusing on the
loudest customer requests, teams can compare feature requests with
actual usage patterns from similar user groups. This helps predict
the impact before committing engineering resources.
Identifying expansion revenue opportunities: Usage-based triggers,
such as a user nearing their plan limit or using a feature that
typically leads to upgrades, can highlight accounts that are ready
for a sales conversation or an in-app upsell prompt.
Spotting churn risk early: Declining engagement scores, less
frequent logins, or incomplete key workflows often happen weeks
before someone cancels. Catching these signs early gives customer
success teams a chance to intervene.

The common thread among all these points is that SaaS analytics works best when it is part of daily workflows, rather than reviewed quarterly in a static report.

Conclusion

SaaS analytics and product intelligence are essential for growing software companies. They serve as the foundation for making decisions based on evidence instead of guesswork. From clean event tracking to cohort-based retention analysis, the aim is to connect what users do with why they do it. This connection helps create a product that users want to keep using. Teams that invest in this foundation early move faster, waste less engineering time on features that go unused, and catch problems before they become costly.

Frequently Asked Questions

1. What is the difference between SaaS analytics and product analytics?

SaaS analytics looks at business-level metrics like MRR, churn rate, and customer acquisition cost. Product analytics focuses on in-app user behavior, such as feature usage and session flows. Most modern platforms combine both for a full view.

2. What metrics matter most for SaaS growth?

Key metrics include monthly recurring revenue (MRR), churn rate, customer lifetime value (CLV), feature adoption rate, and net revenue retention. The right mix depends on whether the emphasis is on acquisition, retention, or expansion.

3. How do I choose the right analytics tool for my SaaS product?

Look for tools that integrate well with your current tech stack and support the level of event tracking you need. They should not require constant engineering help to manage. API-first platforms usually scale better as needs change.

4. Can small SaaS startups benefit from product intelligence, or is it only for large companies?

Small teams often gain the most benefit because early data helps confirm product decisions before scaling. The key is to start with a few important metrics rather than trying to track everything at once.

5. How often should SaaS teams review analytics data?

Important metrics like activation rates and churn signals should be watched continuously or weekly. Broader strategic metrics like retention cohorts are usually reviewed monthly or quarterly to identify trends.

Every Feature Proposal Is an Argument: What 1958 Philosophy Teaches Product Teams

Wed, 03 Jun 2026 00:42:25 +0000

Originally published at vibeagentmaking.com

80% of features in B2B software are rarely or never used. 12% drive 80% of daily usage. This isn't a prioritization-framework problem. It's an argumentation problem.

The Hidden Warrant

In 1958, S. Toulmin published The Uses of Argument, decomposing practical argument into claims, grounds, warrants, and rebuttals. The part product teams almost always skip is the warrant -- the usually-unstated principle linking data to conclusion.

"We should build SSO" is the claim. The 62% request rate is the grounds. The warrant -- "enterprise feature requests reliably predict enterprise revenue" -- is never stated, never inspected, and might be wrong.

Where Arguments Die

Product management produces hidden warrants at scale:

Customer requests predict usage. Pendo's 80% stat says otherwise.
Competitor parity drives retention. More often, the competitor shipped it because their customers asked too, and nobody used it there either.
Our biggest customer's feedback generalizes. The biggest customer is, by construction, an outlier.

Kohavi's 1/3 rule: when warrants are actually tested, one in three ideas is positive, one in three is flat, one in three is negative.

Why RICE Isn't Enough

Frameworks that make warrants visible (Kano, Opportunity Scoring) are discovery tools. Frameworks that hide warrants (RICE, ICE) are ranking tools. A culture relying on RICE alone stacks ranked claims on unexamined warrants.

The HiPPO Problem

The HiPPO rarely brings grounds. She brings a claim and a silent warrant: I have taste. The fix: require a warrant section in every proposal regardless of seniority. The HiPPO now writes her reasoning down where it can be cross-examined.

What Changes Monday

Every proposal has a warrant section: "These grounds support this claim because [causal theory]."
Every proposal has a rebuttal section: "This feature will have failed if [condition] by [date]."
Reviewers attack the warrant, not the data.
Same template for the HiPPO and the intern.

A small improvement in warrant quality compounds hard against that 80% baseline.

AI Makes Us Faster. Agile Keeps Us Pointed in the Right Direction.

Wed, 20 May 2026 04:54:12 +0000

AI coding tools are changing the development loop.

With tools like Claude Code, Cursor, and GitHub Copilot, a solo developer can build screens, wire APIs, generate logic, and deploy much faster than before.

That is exciting.

But it also creates a new problem.

If we can build faster, we can also move in the wrong direction faster.

That is why I started thinking about Agile again.

Not as a set of meetings.
Not as Scrum rituals.
Not as a way to increase velocity.

But as a way to validate direction.

Speed does not replace direction

Before AI, implementation was often the bottleneck.

Even if a team knew what to build, actually building it took time. That slow process naturally created moments to think, question, and refine the direction.

Now the implementation loop is much faster.

You describe a screen, and code appears.
You describe an API, and endpoints are generated.
You describe a workflow, and an assistant can produce a working draft.

That speed is useful. But it can also hide a dangerous pattern.

You ship one feature, then immediately see the next one.
Then the next.
Then another.

Before asking whether the current feature actually solved a real problem, you are already building the next thing.

Fast completion is not the danger.
Fast certainty is.

Agile was never just about moving faster

Agile is often misunderstood as a fast development methodology.

Run sprints.
Do standups.
Track velocity.
Ship often.

But the deeper point of Agile is not speed.

It is feedback.

Build something small enough to test.
Show it to real users.
Observe what changes.
Adjust direction before the cost of being wrong becomes too high.

A sprint without feedback is just Waterfall with shorter cycles.

This matters even more in the AI era.

AI can accelerate the “build” part of the loop. But it does not automatically answer the more important questions:

Who is this for?
What problem does it solve?
Is this problem painful enough?
Did the user actually need this?
What did we learn after shipping?
Are we improving the product, or just adding more features?

Those questions still belong to people.

For solo developers and founders

This is especially important for solo developers and indie founders.

AI makes it easier to build an MVP in a day.

But an MVP is not just a smaller product.
It is a smaller piece of evidence.

A landing page can be an MVP.
A manual workflow can be an MVP.
Five user interviews can be an MVP.

The goal is not to prove that you can build something.
The goal is to test whether the problem is real.

For founders, Agile is less about team process and more about hypothesis validation:

Problem hypothesis
Customer hypothesis
Channel hypothesis
Pricing hypothesis
Retention hypothesis
Feature hypothesis

If the problem hypothesis is wrong, building more features will not save the product.

For teams using AI

In teams, AI can increase output quickly.

More tickets closed.
More pull requests opened.
More features shipped.

But more output does not always mean more product value.

A team can ship eight AI-assisted features in a sprint and still see no change in retention, activation, or user satisfaction.

That is why the Definition of Done also needs to evolve.

In the AI era, “done” should not only mean:

code reviewed
tests passed
deployed successfully

It should also ask:

Can the team explain the AI-generated code?
Does this feature solve a specific user problem?
Is there a way to observe whether it works?
Did we define what we expect to learn?
Will this change inform the next decision?

AI can help us build faster.
But direction still needs to be verified.

Agile as a direction validation loop

The way I now understand Agile is simple:

Question → Hypothesis → Build → Observe → Adjust

AI can accelerate Build.
It may also help with Observe.

But Question, Hypothesis, and Adjust still require human judgment.

That is where Agile still matters.

Not because teams need more rituals.
Not because every company needs Scrum.
Not because velocity should go up.

But because faster development makes wrong direction more expensive.

I wrote a longer Deep Dive on this idea here:

https://dechive.dev/en/deep-dive/ai-era-agile-verification

The Indie Hacker’s Manifesto: Stop Coding, Start Shipping

Sat, 25 Apr 2026 11:39:31 +0000

I. Strategy: Finding the "Arbitrage of Mediocrity"

1. The Differentiation Framework

The "Goldilocks" Niche: Don’t go so niche that the market doesn’t exist. If there’s zero competition, there’s likely zero money. Aim for "Niche but Scalable."
Dimensional Attacks:
- Attack Open Source: Most OSS tools are powerful but "ugly," hard to configure, and lack support. Your opportunity? Build a Better UI/UX Wrapper that provides a "plug-and-play" experience.
- Unbundle the Giants: SaaS giants (Salesforce, Adobe, Jira) are bloated, expensive, and forced subscriptions. Your opportunity? Build a Lightweight, Privacy-First, One-Time Payment alternative for just one specific feature.
- The 3-Star Arbitrage: Scour Product Hunt or the App Store for famous products with a 3.2-star rating. Read the complaints. Fix that one specific pain point and release it as a standalone micro-tool.

2. Geopolitical Arbitrage

Willingness to Pay (WTP): Target markets with high disposable income and a culture of paying for software (North America, DACH region, UK).
Ignore Low-Value Noise: Don't waste your support time on markets that demand "free" unless you are building a non-profit.

II. Development: Escaping the "Productivity Porn" Trap

3. The "Embarrassment" Principle

Core Logic Only: If a feature doesn't solve the primary pain point, it’s a distraction.
The Reid Hoffman Rule: "If you are not embarrassed by the first version of your product, you’ve launched too late."

4. The Developer’s Comfort Zone

Stop Building Tools for Yourself: Spending three weeks writing a "custom Twitter bot" instead of actually talking to users is just procrastination disguised as work.
The 70/30 Rule: Spend 30% of your time coding and 70% marketing. Great code that nobody finds is just a graveyard of wasted hours.
Code Freeze: Once you launch, stop touching the CSS. Unless it’s a critical bug, put the keyboard away and pick up the megaphone.

III. Marketing: Weaponizing Distribution

5. High-ROI Channels

Channel	Why it Works	The Catch
Reddit	High intent, niche subreddits.	They hate "Salesmen." Must provide value.
X / Twitter	The home of "Building in Public."	Requires consistent personality.
Hacker News	Can trigger massive viral traffic.	Highly critical audience. No marketing fluff allowed.
Product Hunt	The "Grand Opening" of the tech world.	Only lasts 24 hours. Needs a launch strategy.

6. Fighting the Algorithm

Human-to-Human (H2H): Platforms hate "Corporate" ads. Use Storytelling. Talk about your failures, your tech stack, or "The one thing I learned building X."
The Incognito Test: Always check your posts in Incognito/Private mode. If you don't see it, you've been shadowbanned or filtered. Don't wait for stats—verify visibility immediately.

IV. The Moat: Trust & Passive Traffic

7. Trust Engineering

Show, Don't Tell: In an era of AI scams, trust is the only currency. Offer "Local-First" processing, "No-Tracking" guarantees, or high-quality interactive Demos that don't require an email signup.
Zero-Friction Entry: Reduce the "Aha! Moment" time. If I have to confirm my email and set up a profile just to see how your tool works, I'm already gone.

8. AIEO (AI Engine Optimization)

Programmatic SEO: Create landing pages for "Long-tail" keywords (e.g., "Best lightweight Alternative to X for Mac").
The llms.txt Standard: Deploy an llms.txt file in your root directory. This provides a clean, markdown-based summary for LLMs (ChatGPT, Perplexity, Claude) to read. When a user asks an AI for a "tool that does X," you want the AI to recommend you.

V. Post-Launch: Surviving the "Trough of Sorrow"

9. The 72-Hour Rule

After the initial launch buzz, your traffic will drop to near-zero. This is normal. Do not panic. Do not rewrite the codebase. Stick to your marketing plan for at least three days before making a pivot.

10. The Asset Mindset

Everything you build—the domain, the code snippets, the backlinked landing pages—is Digital Real Estate. Even if the product fails to generate revenue today, the "Domain Authority" and the "Skill" you’ve built are assets for your next ship.

The Bottom Line: Be a Marketer who knows how to Code, not a Programmer who "tries" to Market.

author web Organization

BuildInPublic #IndieHackers #Solopreneur

What to Build Next After You've Vibe-Coded Your First App

Mon, 23 Mar 2026 05:22:36 +0000

You vibe-coded your app. It's live. People can use it. And now you're sitting in front of a blank roadmap with twenty ideas and no idea which one actually matters.

Your Replit project or Lovable app got you here faster than you expected. The AI generated the code, you iterated on it, you shipped. That part was almost fun. But now the adrenaline of launching has worn off and you're facing a different kind of problem.

You could add a notification system. You could build an admin dashboard. You could integrate with Stripe. You could redesign the onboarding. You could add a team feature. You could build out the mobile version. Any of these could be the thing that unlocks growth. Or any of them could be a week wasted on something nobody wanted.

Every day you spend building the wrong thing is a day of runway you don't get back. And if you're a non-technical founder, figuring out "what's the right thing" feels like guessing in the dark. Your dev team or your AI tools can build whatever you tell them to build. The hard part is telling them the right thing.

Building a product has never been easier. AI code tools and no-code platforms made the construction part cheap and fast. But that speed made something else very visible: the real risk was never building. The real risk is building the wrong thing. And the cost of being wrong just accelerated because now you can waste a sprint in days instead of months.

At Wednesday Solutions, we've spent 15+ years helping founders - especially non-technical founders - figure out what to build and why. Our Sprint Zero process replaces the blank roadmap with a Traction Roadmap: we map your funnel with real data, identify where it's leaking, run user conversations to find the root cause, and hand you 2-3 scoped sprints with success metrics - all in about two weeks. We carry a 4.8/5.0 rating on Clutch across 20+ reviews, mostly from founders who were staring at the same blank roadmap you are right now. We recently helped a vibe-coded app go from launch to $50,000 in revenue in one week - not by building more, but by building the right thing.

Here's the system for making that call with confidence.

Step 1: Pick the one number that decides what you build

When you sit down to plan what's next, the instinct is to think in features. "We should add notifications." "Let's build a dashboard." "Competitors have a calendar view, we need one too."

The problem is that none of those are connected to why your business isn't growing.

Instead, pick the one number that matters most right now. Not ten numbers. One. And make it something specific.

How many people come back a second time after signing up? How many people who start using the product actually get to the good part? How many free users become paying users? How many users are still active after 30 days?

If you're not sure which number to pick, ask yourself: if I could only change one thing about this business in the next 90 days, what would make the biggest difference to survival? That's your number.

Now every decision about what to build connects to that number. If a feature doesn't have a clear path to moving that number, it goes on the shelf - no matter how cool it sounds, no matter how easy it would be to vibe-code in a weekend.

Step 2: Talk to your users before you build for them

Here's where most founders go wrong. They brainstorm features, look at competitors, read product blogs, and pick something that feels right. Then they build it and wonder why nothing changed.

The fastest path to knowing what to build is talking to the people who use your product - or who tried it and left.

Pick up the phone or jump on a video call with five to ten of your actual users. And when you do, don't ask about your product. Ask about their life.

"Walk me through the last time you tried to [the thing your product helps with]." "What was annoying about that?" "What did you try before you found us?" "What almost made you give up?"

You're not looking for feature requests. You're listening for patterns. When three different users describe the same frustration in different words, that's your signal. Write those down. Those are the real problems you should solve next.

This is hard if you're not used to it. Your instinct will be to pitch, to explain, to defend your product. Resist. Just listen. The gold is in what they say when you stop talking.

Step 3: Understand what your product was actually hired to do

Your users didn't download your app because they wanted software. They were trying to make progress on something specific in their life or work. Your app was their attempt at making that progress.

That progress has three layers, and most vibe-coded apps only serve one of them.

The first is the practical layer. The task they need to get done. "I need to track my invoices." Most apps handle this fine.

The second is the emotional layer. How they want to feel. "I want to feel like I'm on top of my business instead of drowning in paperwork." Most apps completely ignore this.

The third is the social layer. How they want to be perceived. "I want my clients to see me as professional and organized." Almost no early-stage app touches this.

When you listen to those user conversations, pay attention to all three layers. The practical needs tell you what features to build. The emotional needs tell you how to design the experience. The social needs tell you how to position the product.

The feature that moves your number might not be a new capability at all. It might be making the existing capability feel different - more reassuring, more professional, more like progress.

This is a specific blind spot for vibe-coded apps. The AI tools are great at generating functional features - screens, buttons, flows. They have no ability to design for how something makes a user feel. That layer is entirely on you, and it's usually the missing piece.

Step 4: Score your options before you build any of them

Now you've got real problems from real users, connected to the one number you're trying to move. The temptation is to jump straight to a solution. Don't.

For every user need you uncovered, score two things on a 1-to-10 scale. How important is this to them? How well does their current approach handle it - including your app and whatever they used before?

High importance plus low satisfaction is where you build next. That's the gap where your users are underserved and would notice if you filled it.

This sounds simple but it's ruthlessly effective at killing pet features. That Stripe integration you've been wanting to build? If users rate payment as low importance right now because they're not even staying long enough to pay, it doesn't matter. The confusing first screen that loses 60% of new users in the first minute? If that scores high importance and low satisfaction, that's your next sprint.

Step 5: Come up with three solutions, test cheap, then build

For every problem worth solving, force yourself to come up with at least three different ways you could solve it. The first idea is almost never the best one. It's just the most obvious.

Maybe users are dropping off during onboarding. You could build a tutorial walkthrough. You could simplify the first screen to show only one action. You could send a welcome email that explains the three things to do first. Those are very different solutions with very different costs and timelines.

Before you build any of them, find the cheapest way to test whether the idea works.

If you think a welcome email would help, write it yourself and send it manually to the next ten signups. See if their behavior changes.

If you think the first screen is confusing, jump on a call with three new users, share their screen, and watch them try to use the product. You'll see exactly where they get stuck.

If you think a new feature would keep people coming back, describe it to five users and ask "would this change anything for you?" Watch their reaction carefully. Energy and specifics mean something. "Yeah, that's cool I guess" means nothing.

The point is that you should never spend real development time on something you haven't tested cheaply first. Every feature should have evidence behind it, not just a hunch.

Step 6: Check for the signal before you scale

After you've built and shipped something based on real user evidence, don't immediately jump to the next feature. First, check whether what you shipped actually moved the number.

Did retention go up? Did more users reach the moment of value? Did conversion improve?

If yes, you're learning. Do more of what worked. Go deeper on the same problem. Make the solution even better for the same people.

If no, that's learning too. Go back to step 2. Talk to more users. The problem you identified might be right, but the solution might not be. Or the problem might matter less than you thought and a different one matters more.

This loop - talk to users, identify problems, test solutions cheap, build the winner, check the number - is the system. It replaces the blank roadmap with a process that gets sharper every cycle. Each time through, you learn something that makes the next decision better.

There's a simple test for whether you've found the thing that matters. Ask your users: "How would you feel if you could no longer use this product?" When 40% or more say they'd be very disappointed, you've earned the right to scale. Until then, keep running the loop.

A note about when the codebase is the blocker

Everything above assumes you can iterate on your product quickly. For some vibe-coded apps, you can't - not because you're slow, but because the codebase is too fragile.

If making a change to the onboarding breaks the payment flow, if you can't add analytics without a significant rewrite, if the architecture is so tangled that a one-day change takes a week of debugging - then the code is blocking your ability to learn. And if you can't learn, the loop above doesn't work.

The right approach is to assess the product and the codebase at the same time. If the foundation needs rebuilding, do that first. Not a full rewrite from scratch - just enough stability that you can iterate safely. Then run the loop.

The roadmap isn't a list. It's a loop.

The difference between founders who grow and founders who stay stuck isn't that the first group picks better features. It's that they have a system for figuring out what to build next - and it starts with users, not with brainstorming sessions.

At Wednesday Solutions, we run this exact loop with founders through Sprint Zero. In two weeks, we map your AARRR funnel with whatever data you have, identify the primary leaky stage, run at least five user conversations, and deliver a Traction Roadmap - a diagnosis of what's broken and 2-3 scoped Vibe Sprints to fix it. Each sprint targets one funnel stage, ships a scoped outcome in two weeks, and has a success metric defined before work begins. Outcome not met, you don't pay. That's how confident we are in the process.

We also run a lightweight tech assessment as part of Sprint Zero, so you'll know whether your vibe-coded codebase can support the changes or whether the foundation needs work first. No 50-page report. Just a clear answer: can we iterate on this, or do we need to shore it up?

Anuj Kejriwal, founder of Spotwriters, described working with us: "The most impressive and unique thing about Wednesday was their ability to grasp exactly what we need. We are on track to get to our product in just 4 months. I have made numerous changes to the project since Day 0 and the team has swiftly incorporated these changes. They work really fluidly and are great at finding simpler solutions to complex problems."

Your vibe-coded app got you to launch. Figuring out what to build next is the game now. And it's a game you win by listening, not by building faster. Check out how we helped a vibe-coded app go from launch to $50,000 in revenue in one week.

Questions founders ask us

I used Lovable to build my app and launched it, but I have no idea what to do next. Where do I start?

Start by ignoring your feature backlog. The first thing to do after launch is talk to the people who signed up. Not a survey - actual conversations. Ask them what they were trying to do when they found your app, what their life looked like before they tried it, and what happened when they used it. You will learn more from five of these conversations than from a month of analytics. The patterns that emerge from those conversations tell you what to build next - and more importantly, what to stop building.

I vibe-coded my product and got my first users. How do I know if people actually want what I built?

Track actions, not opinions. If people say they love your product but don't come back, they don't actually love it. Look for three signals: do users return without you prompting them, do they tell other people about it without you asking, and would they be genuinely upset if you took it away tomorrow? If you surveyed your users right now and fewer than 40% said they would be very disappointed without your product, you have not found a fit yet. That is not a failure - it is a signal that you need to dig deeper into what specific users value most and double down on that.

My vibe-coded app has users but none of them are paying. What should I change?

Free users who don't convert usually means one of two things: either they don't see enough value to pay, or the value they see feels like a nice-to-have rather than a must-have. The fix is not to add a paywall and hope. The fix is to find the users who use your product the most and figure out what is different about them. What specific problem are they solving with it? What would they have to go back to doing without it? Then rebuild your positioning, onboarding, and pricing around that specific use case. At Wednesday Solutions, we call this finding your tightest problem-solution fit before you scale.

How do I figure out which features to prioritize for my startup?

For every feature idea, ask two questions: how important is this to the people who use my product the most, and how well does their current solution handle it? If something is very important to them and nothing else does it well, that is your opportunity. If something is important but they already have a good workaround, skip it. This prevents the most common trap seed-stage founders fall into - building features that seem exciting but don't move the needle on retention or revenue.

Is my vibe-coded codebase going to be a problem when I try to scale?

Maybe, but probably not in the way you think. Most vibe-coded apps don't fail because of code quality - they fail because the founder rebuilt for scale before they had anything worth scaling. The right sequence is: first prove that users want what you've built and will pay for it, then assess whether the code can handle the growth. A lightweight tech check - not a full rewrite - is usually enough to tell you if your foundation holds for the next 6 months. If it does, focus on product. If it doesn't, scope a targeted rebuild of just the parts that will break. Wednesday Solutions includes this assessment as part of every Sprint Zero engagement.

If you've vibe-coded your first app and you're not sure what to build next, we run Sprint Zero engagements for exactly this moment. Two weeks. One deliverable: a Traction Roadmap that tells you what's broken, why, and what to fix first. See what other founders have said about working with us on Clutch.

Looking to Connect with Devs/Builders to Start Something Together

Fri, 08 Aug 2025 05:37:40 +0000

I’m a solo builder. I’m looking to connect with like-minded devs who want to explore startup ideas together — maybe even apply to Y Combinator if it feels right.(Area mainly is AI)

Not pitching any fixed idea right now — just open chats, bouncing thoughts, and seeing if there’s a good vibe to build with someone. If you’re curious, motivated, and want to work on something meaningful, let’s connect!

Drop a comment or DM me here. I’d love to talk.

Coder Legion - Recent posts tagged product

Multi-tenant SaaS, explained with a football academy

The building: what a tenant is

The rooms: roles

Three ways to share a building

The noisy neighbour

The scary one: data leaks

How I'd think about it

FAQ

What is a tenant in SaaS?

Is a shared database with a tenant ID safe?

What's the difference between multi-tenancy and RBAC?

Sources

What next

Shipping Android and iOS solo (iOS: coming soon)

Building it is the part you expect

The two doors: Play Console and App Store Connect

Google's 12 testers and 14 days

Apple's reviewers read the guidelines so you have to

Why Android first, for us

What I'd tell another solo dev

FAQ

Is the Track My Academy iOS app out?

Do new Google Play developers need testers before going live?

How much does it cost to publish on both stores?

Sources

What next

I built a pager for my own developers

A very old idea

Why a small team needs one

The rules I'd steal from Google

The danger: a pager that cries wolf

What I think a good internal pager should do

About those certificates

The point

FAQ

Does a small team really need alerting?

What should trigger a page?

How do I avoid alert fatigue?

Sources

What next

How to win a hackathon, according to a tired judge

What hackathon judges actually see

The first 30 seconds of your hackathon pitch

Show the prototype early

How to win a hackathon: stay on the problem statement

Don't over-engineer your hackathon project

What the jury doesn't want to hear

A simple hackathon pitch structure

Hackathon tips for the questions round

FAQ

How do hackathon judges score projects?

How long should a hackathon pitch be?

Do you need a perfect product to win a hackathon?

Go build something

R.I.P. smart ball v1: what smart football sensors taught me

The idea: a football that knows it was kicked

Prototype zero: maida, boba straws and a pickleball

What was inside smart ball v1

The year in one list

Our first PCB, made in Coimbatore

IMU vs piezo sensors: two ways to make a ball feel things

Meanwhile, the professionals

The real engineer: Jitendra

I learned to solder (soldering safety first)

Why hardware is hard (and why v1 never shipped)

Hardware prototyping for beginners: what I'd tell you

FAQ

What sensors are used in smart footballs?

Is a smart football hard to build as a beginner?

Is soldering safe for beginners?

The funeral is over

Outsourcing vs building it yourself: our app arrived from 2006

The idea was simple

Then the build arrived

The stupidest ₹50,000 I've ever spent

Outsourcing app development vs building it yourself

How to write a product brief that doesn't come back from 2006

The first night of building a SaaS MVP myself

The modern stack I ended up with