How to test your app before launch (my actual method)

Let me give you my personal method for private testing, because a method beats motivation every time.

First, I ask Claude for a list of all the pages on my platform. Then I ask for a list of the functions attached to each of those pages. Then, instead of testing randomly, I ask Claude to design a plan to test those functions in phases. And then we work through that plan together, testing against my own account on the live platform.

Yes, you can give Claude an email and password so it can actually run through things as a real user would. One piece of grown-up advice while you do that: use a dedicated test account, not the personal password you reuse across your whole life. Make a clean account, give it those keys, and keep your real credentials your own. Sensible, not paranoid.

On the subject of methods: due to popular demand — and frankly because some of you are gloriously lazy — I have prepared a definitive how-to for all of this, including my own personal prompting techniques that save you a serious amount of tokens. Tokens are money, and clumsy prompting burns them.

Then you test it yourself, by hand, and hate it

After Claude has run its own testing pass, I test the thing myself. On the live site. Going through every single function, one after another, by hand.

I will not lie to you. This is not glamorous. It is, in fact, deeply annoying. It is the opposite of the fun part. But it is non-negotiable, because the rule is simple and merciless:

Find your bugs before your users do, or your users will find them for you.

And users finding your bugs is the expensive way. They do not file polite reports. They just leave, quietly, and never come back, and you never even learn why. So you sit there and you test, you fix, you test again, you fix again, and you repeat the loop until you are actually happy. Not until you are tired. Until you are happy.

Optimisation one: why your images should be WebP, not JPEG

For this part, I had to spend real time combing through YouTube to get a proper idea of what I was doing, and you may have to as well, and that is completely fine. But a lot of it, honestly, was just common sense once I sat down and looked. The core realisation was this: I was being far too generous with space, and generosity with space is a slow, expensive death.

So here is what I did — and these are the answers to last week's JPEG question.

I limited photos on a profile to five maximum. I am not trying to be Instagram here. Nobody needs forty pictures on a profile in the kind of product I am building.

I put a five megabyte cap on uploads. Listen, my platform is not the place for your enormous layered Photoshop file. It is not my system you will come and break, my friend.

But the limits were not enough. The real win was the format. I asked Claude to store images as WebP and HEIC instead of JPEG, because these modern formats save you an enormous amount of space for the same visible quality. Think about it. If you are building a mobile-first app, what are you doing serving people resolutions meant for a billboard? On a small screen, the average eye genuinely cannot tell the difference, but your storage bill and your load times can.

One honest note, since you will go and do this yourself: WebP is your reliable hero because browsers display it everywhere. HEIC is brilliant for compression and for Apple devices, but it does not display natively in most browsers. So a safe pattern is to lean on WebP for what you actually serve to the web, and treat HEIC as a storage and Apple-side advantage rather than your universal delivery format. Ask Claude to handle the conversion sensibly for each surface.

You are not running a photo museum. Serve the smallest thing that still looks right on the screen it is going to.

Optimisation two: stop talking to your database so much

Then I did the thing I should have done from the start, which is simply ask Claude directly to look for areas it could optimise. You have a super senior engineer on call. Use it as one.

The biggest thing it found embarrassed me a little. All of my database calls were set to live. Every impression, every click on an ad, every notification for practically every action a user took — my system was hammering the database in real time to track and report all of it. For a platform trying to monitor things like ad impressions and clicks, that is a quiet catastrophe. You are paying, in money and in strain, for a level of immediacy that nobody actually needs.

So I changed it. Instead of live, I had it sweep every sixty seconds: collect the activity, then report it in a batch once a minute. The numbers a human looks at do not need to be accurate to the millisecond, and that single change took an enormous load off my database.

Now, your situation will differ from mine, and I want to be clear about that:

The kind of site you are running determines which optimisations actually matter. There is no universal checklist. There is only "ask what your specific product is wasting, and stop wasting it."

Optimisation three: stop loading the whole world

The last one is the simplest and the most satisfying. I capped the results displayed at twenty, with a "load more" toggle underneath.

Before that, the platform was happily trying to load bottomless lists of results, draining people's data and slowing everything down, for content that almost nobody would ever scroll to. Because be honest with yourself: how many times in your life do you actually search past the first page of anything? You load the first sensible batch, and you let the rare, determined user ask for more. Everyone else gets a fast, light experience, and you get a cheaper, calmer system.

While we are here, this is also where the second question from last week quietly gets answered. People's email addresses are not identities to be displayed. An email is a private credential, not a public name tag. So as part of this same clean-up pass, you stop using emails as the thing you show on the front of the house, and you give people a proper username or display name instead. Common sense — but the kind that only becomes obvious once you go looking for waste and risk together.

Hands-on lab

The chapter above is the why. These guides are the how. The one rule never changes: if a step stumps you, screenshot it and paste it to your AI with "assume I have no technical experience; tell me exactly what to click next." Nothing here cannot be undone.

G4.1 · Run a full test pass with Claude [Core]

What you'll have: A systematic sweep that catches bugs before users do.

Before you start: Beginner · ongoing · free · you'll need a working app and a test account (G4.2)

1. Ask Claude for a list of all pages in your app.
2. For each page, ask for the list of functions and actions on it.
3. Ask Claude to write a phased test plan covering those functions.
4. Work the plan together, testing against your test account.
5. After Claude's pass, test it yourself by hand on the live site, function by function.
6. Test, fix, repeat until you are happy, not just tired.

Check you did it right: Every listed function behaves as intended.

If something looks off: Too much to test → prioritise the core journey first.

G4.2 · Create a safe test account for Claude to use [Core]

What you'll have: A way to let Claude test as a real user without exposing your personal credentials.

Before you start: Beginner · ~10 min · free · you'll need your auth working

1. Create a dedicated test account on your platform with a fresh email and a unique password.
2. Do not reuse a password you use anywhere else.
3. Share only this test account's credentials with Claude for end-to-end testing.
4. Disable or rotate it before launch if you like.

Check you did it right: Claude can log in and act as a normal user via the test account.

If something looks off: Just never use personal or reused passwords here.

G4.3 · Set image limits (count and file size) [Optional]

What you'll have: Protection against storage bloat and abuse.

Before you start: Beginner · ~30 min · free · you'll need an upload feature

1. Decide your limits (for example, 5 photos per profile, 5MB per upload).
2. Ask Claude to enforce a maximum number of images per profile.
3. Ask it to reject oversized uploads with a friendly message.

Check you did it right: Exceeding the limits is blocked cleanly.

If something looks off: Legitimate large files rejected → adjust the cap to your real needs.

G4.4 · Convert and serve images as WebP [Optional]

What you'll have: Much smaller images, faster loads, lower bills.

Before you start: Beginner–Intermediate · ~1 hr · free · you'll need image uploads

1. Ask Claude to convert and serve images as WebP (supported across browsers).
2. Resize to screen-appropriate dimensions; no billboard resolutions for phone screens.
3. HEIC is great for Apple and storage but does not display natively in most browsers, so use WebP for web delivery.

Check you did it right: Uploaded images are served as smaller WebP files and still look right.

If something looks off: Images not displaying → if you served HEIC to browsers, switch web delivery to WebP.

G4.5 · Batch your database calls (live to an interval sweep) [Advanced]

What you'll have: Big savings by not hammering your database in real time.

Before you start: Intermediate · 1–2 hrs · free · you'll need analytics or notification features

1. Ask Claude to audit which calls are set to live or real-time.
2. For things that do not need the millisecond (impressions, clicks, most notifications), switch to a periodic sweep — for example every 60 seconds — that batches and reports.
3. Keep genuinely time-sensitive things live.

Check you did it right: Database load drops while metrics still update on the interval.

If something looks off: Something feels laggy that shouldn't → keep that specific call live.

G4.6 · Add pagination with a "load more" toggle [Optional]

What you'll have: Faster pages and less wasted data.

Before you start: Beginner · ~45 min · free · you'll need any list or feed

1. Ask Claude to cap results at about 20 per load.
2. Add a "load more" button for users who want more.
3. Apply it to feeds, search results, and long lists.

Check you did it right: Lists load a fast first batch with a working "load more."

If something looks off: Important items hidden → tune the default sort order.

Do you have a product, or an expensive hobby?

So I finished all of this. Limited, compressed, batched, paginated, cleaned. And I sat back and thought: right, time to test once more. But this round was different. This time I was not hunting for broken buttons. I was simulating the real user experience, walking the full journey a stranger would walk, to answer the only question that actually matters.

Do I have a product? Or have I just been blowing money, fast, on a very elaborate hobby?

Look at everything tonight was about: saving space, saving tokens, saving database calls, saving your users' data. This whole chapter was about doing more with less, because less is what most of us start with.

That is exactly why I keep begging you not to do this alone. Africa cannot win this as ten thousand separate founders each burning their small savings on the same lessons in private. We move as an ecosystem or we move slowly. Some of us share hosting, some share tokens, and some of us just write down everything we learned the painful way so the next person does not have to bleed for it. That is what the AIStoryLab community is: the definitive how-tos, my token-saving prompt techniques, plain-language guides to every term I have thrown at you, and resources donated by builders walking your exact road.

What's next

You have a tested, optimised, genuinely lean platform now. Next comes the phase that taught me the deepest lesson of this whole journey: products are not simply made, they are iterated. You do not finish a product. You begin a relationship with it. Next time, we find out whether what you built is actually a product.