Drafts

We're building a POS system and CRM for local businesses in Pakistan — and I'm running the entire thing through Claude, start to finish. Not as a gimmick. As an actual test of how far this workflow can go. Here's the sequence we settled on: First, research. Before writing a line of code, I have Claude dig into how similar systems handle inventory, receipts, and daily cash reconciliation — the messy stuff local shops actually deal with, not textbook features. Then architecture. We plan the whole structure together before touching the UI. This is the step most people skip, and it's the one that saves you from rebuilds later. Then UI mockups with Claude's design tools, so the shop owner can see something real early instead of me describing screens over a call. Only then do we build, with Claude working alongside our engineers. What surprised me: the research and planning phases are where AI earns its place. The building is fast, but fast building on a weak plan just gets you to the wrong place quicker. What it doesn't replace: judgment about what a Pakistani corner-shop owner will and won't tolerate in daily use. That still comes from talking to real people. I'm treating this build as a working experiment, and I'll share what breaks too. If you've shipped a real product this way — where did you stop trusting the AI and take the wheel yourself?

Most people open an AI coding tool and start with the screens. I've learned to do the opposite. We're building a POS and CRM for local businesses here in Pakistan — the corner pharmacy, the fabric shop, the small restaurant that still runs on a paper register. And the first thing we're doing is nothing visual at all. Before any UI, before a single mockup, we're sitting with Claude to plan the architecture. What tables, what relationships, how inventory talks to sales, how a CRM record survives a shop that has spotty internet half the day. Here's what I've figured out the hard way: AI is brilliant at generating UI fast. It'll give you a polished dashboard in minutes. But if the data model underneath is wrong, that speed just helps you build the wrong thing faster. So the order matters. Architecture first, reviewed by our team, not the AI. Then Claude for the UI mockups. Then the actual build with the model in the loop. The AI writes a lot of the code. It does not make the structural decisions. That line is where I've decided to trust it and where I don't. I think a lot of the "AI builds your whole app" excitement skips this part, and the projects pay for it later. For those of you building for small, real-world businesses — where do you draw the line on what the AI gets to decide?

Most local shops in Pakistan still run on a register and a notebook. I want to change that — and I'm building the software with AI doing most of the heavy lifting. Here's the plan for our new POS and CRM for local businesses. I'm not opening Claude Code first. That's the mistake I see people make — they jump straight to generating code and then spend a week untangling decisions the AI made for them. So we go in order: First, architecture planning. What tables, what flows, how a shopkeeper actually moves through a sale. This part is human-led. AI is bad at knowing what a Lahore kiryana store needs — I'm not. Then Claude for the UI mockups. Fast, cheap, and good enough to react to before anything is built. Only then Claude Code to build it out, section by section, against the architecture we already agreed on. The thing I've learned across client projects: AI is brilliant at execution and weak at judgment. When you feed it a clear plan, it flies. When you ask it to decide, it guesses confidently and you pay for it later. We're at the start of this one, so I'll share what breaks as we go. For those of you building with Claude Code — do you plan the architecture by hand first, or let the model propose it and correct from there?

Everyone told me AI would build our whole app. It built half of it — and that half was the easy half. We recently shipped a crypto-based social platform. Users could post like they would on any feed, a coin was launched through it, and live coin numbers ran across the app. For the front end, we used Lovable. Honestly, it was excellent. Layouts, states, the interface — it moved faster than any human team I've watched do the same work, and the quality held up. Then we hit the back end. That's where the story changed. Coin logic, wallet handling, the data flowing between users and the ledger — none of that could be prompted into existence and trusted. We engineered it ourselves, module by module, testing each piece before it touched the next. Here's the line I now draw with founders: let AI own the parts where a wrong output is visible and cheap to fix. Own yourself the parts where a wrong output is invisible until it costs someone money. Front end broke loudly. Back end broke silently. That difference decided who — or what — we let build each layer. The tools got us to launch faster, but only because we knew where to stop trusting them. Where have you drawn that line on your own product?

A lot of founders think AI tools like Lovable can build the whole product for them. They can't — but they can save you weeks if you know where the line is. We recently built a full crypto-based social media platform. Users could post like they would on any timeline, and the platform launched its own coin with live numbers running through it. Here's what actually happened. The front end? Lovable handled it beautifully. Clean, fast, and honestly better than what I expected from a prompt-driven workflow. It gave us a polished interface in a fraction of the usual time. The back end was a different story. Coin logic, transaction handling, the data flowing behind every post — none of that could be hand-waved by AI. We engineered it ourselves, module by module, testing each piece before moving to the next. So the real lesson for me: use AI where it's genuinely strong — UI, scaffolding, fast iteration — and keep human engineering where correctness and money are on the line. Trusting AI to draw a screen is one thing. Trusting it with the ledger behind a live coin is another. If you're building something with real financial stakes, I'd never skip the manual back-end work. Where do you draw your own line between what you let AI build and what you insist on engineering by hand?

Everyone tells you AI will build your whole app. That's half true — and the half they skip is the expensive half. We recently built a crypto-based social media platform. Users could post, a coin was launched through it, and all the live coin numbers ran right inside the feed. For the front end, we used Lovable. Honestly, it was superb. The screens, the flows, the polish — it produced work fast that would've taken us days by hand. Then we hit the back end. Coin logic, live token data, wallet interactions, the rules for how posts and value connect — none of that was something we'd hand to an AI and trust blindly. So we didn't. We engineered it ourselves, module by module, testing each piece before moving to the next. Here's the line I've settled on for client work: let AI move fast where a mistake is visible and cheap to fix. Own the parts where a mistake is invisible until money or data is on the line. Front end broke? You see it instantly. Back end logic broke on a live coin? You might not see it until it's already cost someone. The tools got us there faster overall — but only because we knew which half to slow down for. Where do you draw your own line between letting AI run and doing it by hand?

Before we write a single line of code, one agent does nothing but plan. That one habit cut our rework more than any tool ever did. We stopped treating it as one assistant and started treating it as four specialists. Here's the exact multi-agent setup we now use to design a new web app from scratch. Swipe through, and tell me: are you still running one agent for everything?

Most people use Cursor like a fancy autocomplete. Then they wonder why the code falls apart at scale. We stopped treating it as one assistant and started treating it as four specialists. Here's the exact multi-agent setup we now use to design a new web app from scratch. Swipe through, and tell me: are you still running one agent for everything?