Build in Public: Week 10. Making It Less Fragile
Build in public has a funny way of changing over time. In the beginning you write about ideas, architecture, big plans and bold assumptions. A few weeks later you mostly write about why something broke, how it broke and what you had to fix so it doesn’t break the same way again tomorrow. This week was very much the second kind.
Nothing fundamentally new appeared on the surface though internally a lot of small, slightly annoying, but very necessary things got cleaned up. The kind of work that doesn’t look impressive in a demo, but immediately shows up the moment a real user does something slightly unexpected.
One of the first things we realized is that long-running searches need a way to be stopped, even if everything is technically working as designed. When a search can take ten or twenty minutes, there’s always a moment where you understand you asked the wrong question or just don’t care anymore and want to move on. Until now the system had no real concept of cancellation, tasks would just run to completion because that’s what they were built to do. This week we added proper stop support, so ongoing work can actually be cancelled all the way down, including the Bright Data side.
We also spent some time fixing chat context handling. This wasn’t a single dramatic bug, more like a collection of small papercuts that made the system feel slightly confused in longer conversations. Things like answering a perfectly valid question, but with the wrong mental model of what the user was asking for. Not broken enough to scream about it, but broken enough to slowly erode trust. Those kinds of issues are hard to spot early and very obvious once you do.
Another realization came from the admin side. Different searches have very different costs and not everyone should be able to dial everything up to “expensive mode” just because they can. We added an Effort selector for Instagram searches, but only exposed it in the admin panel. Regular users stay on the cheaper, safer defaults. It’s one of those decisions that feels slightly boring until you start paying real bills.
Authentication was another area where reality hit. Up until now GitHub login was enough for us, mostly because engineers will happily click “Continue with GitHub” without thinking twice. But marketers, which are very much part of the target audience here, do not all have GitHub accounts. This week we added email + password login and wired up confirmation emails via Postmark. That part is currently waiting for manual approval on their side, which is a good reminder that not everything in the stack is instantly automatable, no matter how modern it claims to be.
While we were at it, we also added “Continue with Google”, because at some point you just accept that this button is table stakes. Not exciting, but necessary if you want people to actually get past the login screen.
We also discovered that the Telegram app wasn’t actually working. Not catastrophically broken, just broken enough. That’s fixed now and the Telegram flow is back where it should be.
Overall this was a very unglamorous week. The app got a bit more predictable, a bit cheaper to run and slightly less embarrassing when something goes wrong. At this stage, that feels like real progress.
If you want to see how all of this is wired together, the code is still here:
https://github.com/wykra-io/wykra-api
And if you’ve ever gone through this “everything works except it doesn’t” phase in your own projects you probably know exactly what this week felt like.