Building @Clipriseapp and other online products. 10+ years in digital business. Sharing the decisions, experiments, mistakes and systems behind the work.
10+ years building online businesses, products and systems.
Now I’m building @Clipriseapp in public and sharing the real decisions, experiments, mistakes and results behind it.
No recycled AI advice. Just the work.
I keep close to founder support because the complaint there is often the first product truth. If it cannot bypass the roadmap queue, you are learning too late.
The more AI providers you add, the less any single provider should feel visible. A good abstraction layer turns failure into routing, not a user problem.
Discipline is not always more effort. In a long work block, fatigue starts to blur judgment, and recovery begins when I stop before the next decision turns noisy.
Speed is a feature of a reversible decision, not a universal virtue. A pricing page can be rolled back; a core API or slug choice can’t. Which decision could be tested cheaply instead of debated?
I’ve learned that multiple products add maintenance before they add revenue. The hidden cost is not launch, it’s every API, invoice, and status endpoint you now have to keep alive.
Irreversible decisions deserve more evidence than reversible ones. A pricing page, API, or slug can be changed later; a core decision with high reversal cost can’t. What would be costly to undo six months from now?
A prompt enhancer should stay off when the brief needs control, not interpretation. If it rewrites the intent, the user stops steering and starts guessing.
The gap between an idea and an operator shows up after the first version breaks. The real test is whether the next fix changes the failure state, not the mood.
A risk register is only useful if it tracks unknowns that can still change the plan. If the symptom is a fragile forecast, which layer do you inspect first: demand, pricing, or one unknown that could invalidate your current assumption?
A longer prompt can improve control, until one instruction asks for precision and another asks for freedom. Then the model has a contradiction, not a brief. Which instruction would you delete first from an overloaded prompt?
@tomiarakaki Appreciate the reply mate. Any pointers as I am struggling with that part. 0 tiktok views on 100 vids - thinking to buy new prewarmed acc and/or to go for creators
Building from Zagreb is fine when the API, partners, and customers are global. The local part is still the handoff: one 403, one invoice, one status endpoint that blocks everyone.
Build versus buy is usually about which dependency you want to own. If support tickets or a 403 keep landing on your team, which layer would you inspect first, and which failure would you rather control yourself?