Everything worked perfectly last night. This morning, nothing. A lesson in why you have to test constantly.
I went to bed one evening feeling very pleased with myself. Seven Dinners was looking great. The pricing plans were on the page, the buttons were working, the whole thing felt polished and ready. I had tested everything. I had clicked every button. All good.
I woke up the next morning, made a cup of tea, opened the site on my phone, and clicked the Premium sign up button.
Nothing happened.
I clicked it again. Nothing. I tried the Premium Plus button. Also nothing. I tried on my laptop. Still nothing. The buttons were there, they looked exactly as they should, but clicking them produced absolutely no response whatsoever. It was as if they had decided, sometime overnight, to simply stop working.
This is one of the more baffling experiences of building software without a traditional coding background. Things break for reasons that are not immediately obvious. You did not change the buttons. You did not touch that part of the code. You made a change somewhere else entirely, something that seemed completely unrelated, and somehow it broke something three pages away that you were not even thinking about.
I have since learned that this is entirely normal. Developers have a phrase for it: regression. You fix one thing and break another. It happens to professional engineers working on the largest software products in the world. It certainly happens to a Chartered Accountant building a meal planner in her spare time with the help of an AI.
The Stripe buttons had stopped working because of a code change I had made to the navigation the previous evening. I had been tidying up the mobile nav, removing some duplicate text, and somewhere in the process I had inadvertently altered the structure of the component in a way that broke the checkout flow. The two things were not obviously connected. But in code, everything is connected in ways you cannot always see.
The fix took about twenty minutes once I understood what had happened. But those twenty minutes came after an hour of confusion, testing different things, and gradually narrowing down what had changed between last night when it worked and this morning when it didn't.
What this experience taught me, and what I now do religiously, is to test the whole site every single time I make a change. Not just the thing I changed. Everything. The homepage buttons, the sign up flow, the meal plan generation, the shopping list, the account page. A quick run through the whole user journey every time I push an update.
It takes about five minutes. It has saved me from embarrassing broken experiences for real users more times than I would like to admit.
The other thing it taught me is to make smaller changes. When I first started building Seven Dinners, I would sometimes make ten different changes in one session and push them all at once. When something broke, I had no idea which of the ten changes had caused it. Now I make one change at a time, test it, push it, and only then move on to the next thing. Slower, but so much less stressful.
Building software is a lesson in humility. You think you understand what you have built. Then it breaks in a way you did not anticipate, for a reason you did not foresee, at a moment you did not expect. And then you fix it, and you understand it a little better than you did before.
I genuinely love it. Even the breaking bits. Especially the breaking bits, actually, because those are the moments where you learn the most.
Just maybe not first thing in the morning before the tea has kicked in.
Thoroughly tested, this morning and every morning. Give Seven Dinners a try and let me know if anything breaks — I genuinely want to know!
Try it free →