I've noticed a pattern in almost every "how I built this" thread here lately: before touching the keyboard, people are opening a chat window with an LLM and asking it to poke holes in their idea.
Makes sense. Vibe coding has made building fast. You can go from idea to working prototype in an afternoon. But building fast doesn't mean you're building the right thing faster. If anything, it raises the cost of a wrong guess, because now you can ship the wrong product in a day instead of a month.
So I've started using AI earlier in the process to argue with me. I'll describe an idea and ask it to play the most skeptical potential customer it can, or to list every reason the idea might already be a solved problem. Sometimes that surfaces a competitor I hadn't seen. Sometimes it forces me to actually define the problem instead of jumping straight to the feature list.
Here's the part that worries me though: AI models are notoriously agreeable. If I phrase my idea with enthusiasm, I sometimes get validation back that feels a little too easy like it's mirroring my confidence rather than actually stress-testing the logic. That's dangerous, because it can create false certainty right before you commit real time to building something nobody asked for.
However, when I see someone is already starting to hire an employee, the question crosses my mind: What profit has that person achieved when they can afford to pay another extra person?
We keep seeing things like AI and LLM. But I'm happy about technology products that go beyond the occasional. For example, today I read that Aura is introducing a $499 e-ink digital photo frame that allows you to work without a cable.
I was also happy with the @Flowtica Scribepen from @zaczuo .
A client asks me to fix a bug on a site that another developer built. Before I open the code I cannot know whether it is a one-line fix or a tangle of old plugins and custom code that takes a day.
A fixed price is simple for the client but risky for me if the code is a mess. Hourly is fair to me but clients worry about the bill growing. A short paid diagnosis first, then a fixed price for the fix, is the middle path I have seen, but not every client accepts paying twice.
I had someone take a concept I shared in good faith and launch a lazy clone of it a few weeks later. The silver lining was watching them struggle to execute because they didn't understand the 'why' behind the design decisions. But the trust hit was real and it made me want to build everything in total secrecy.
Moving forward, I started sharing only the problem I'm solving rather than the exact how at least until I have a working MVP. For founders who've had an idea taken how do you set boundaries with collaborators without becoming completely paranoid?
Being an engineer, I tend to think features first.
Still, the time my business grew fastest wasn't after a feature launch. It was after I took advice from someone outside the company and redid the whole site design. Same product underneath.
I've been building a Telegram Mini App recently, and one thing I've spent time on is making sure the backend doesn't blindly trust requests coming from the frontend. It's tempting to assume that because someone opened your app through Telegram, the request is legitimate. But the frontend is still just a client, and requests can be modified. For my project, I started testing what happens when authentication data is missing or modified, and whether protected endpoints reject those requests properly. It reminded me that a working login flow and a secure login flow aren't necessarily the same thing. For developers who've built Telegram Mini Apps or similar embedded apps, what authentication mistakes have you encountered, and how did you catch them during testing?