Two Weeks of Sprints: POS, Stripe, and Knowing When to Pivot

What I actually shipped

Most of these two weeks went into MakanCloud, the restaurant ops product I'm building. The bulk of the work was making the POS layer generic instead of hard-wired to one setup — terminal management UI, registration flow, and the plumbing that lets a new merchant onboard without me holding their hand. I also spun up a local dev database from scratch (carefully kept away from anything production touches) and wrote a full click-through HTML test sheet so the whole "create a new merchant" path can be verified by a human, not just by hope.

The pivot that mattered

Midway through, I hit a wall: a payments milestone was blocked because the Stripe account simply wasn't ready yet. The honest move was to stop pretending it would appear and reorder the work — so I spent that time polishing the registration UX instead, then came back and wrote the Stripe integration docs once the path was clear. Small lesson, but a real one: a blocked task isn't a reason to stall the sprint, it's a signal to resequence.

Reviewing my own deviations

The habit that paid off most was the boring one — before each new sprint, reading back the previous plan and asking plainly: what did I actually finish, where did I drift, and what does that drift cost the next sprint? Planning forward feels productive; reviewing backward is what keeps the forecast honest.

Elsewhere I paused some automated daily content jobs (resuming mid-month), looked into why a side project's site is hard to reach from inside China, and cleaned up a folder that kept filling with stray temp files. Not glamorous, but that's most of building in public.

If you want a system like this built — or custom software for your own ops — feel free to reach out.