What I Built with AI in the Last 7 Days
This past week I worked with AI a lot. I didn't just ask it to write some code. I treated it like an engineering partner I could keep questioning, break problems down with, and look back on the work with.
The week had a clear theme: find the parts of a real product that were clunky, flaky, or hard to operate, and fix them one by one.
Fixing what real restaurants actually run into
MakanCloud now has real tenants using it. So the question isn't "does the feature work?" anymore. It's more detailed than that: when someone is using the system on the floor, does it behave the way they expect?
QR ordering was one problem. After a customer ordered through the QR code on their table, old order data stayed on the page. The POS table status was another. If you switched a table from free to seated and back to free, it could open the add-items or checkout screen by mistake.
These bugs look small, but they hurt a restaurant's trust in the system. My approach was to have AI rebuild the real-world scenario first, then spell out the logic. When should an order show, and when should it be cleared? When is a table status change just a status change, and when should it actually start checkout?
My takeaway: a lot of bugs don't come from bad code. They come from business rules nobody ever wrote down.
Filling the remote support gap
Once real customers were using the product, I noticed a gap: I couldn't remotely help tenants fix problems on-site.
Take a POS printing failure. It could be the terminal settings, the print bridge, a login problem, or the store's network or hardware setup. From the user's description alone, it's hard to narrow it down quickly.
So this week AI and I worked out a remote support plan: how store terminals get registered, how permissions are controlled, how the remote command channel is set up, which steps belong in a runbook, and which actions need to be carefully isolated.
It was harder than I expected. Device registration, network permissions, and different command styles across operating systems all had to be checked one at a time. But it matters. It decides whether I can keep supporting customers after launch or end up firefighting every time something breaks.
My personal site is becoming a long-term home base
The other thread was my personal website.
It used to be mostly a showcase page. Now I want a clearer structure: personal projects, MakanCloud, investment research, tech news, and eventually dev logs.
This week I dealt with the domain, deployment, access from mainland China, moving to a cloud server, and scheduled update jobs. The important part wasn't switching deployment setups. It was sorting out how content production relates to publishing: what gets generated locally, what updates automatically, and which deploy platforms are still watching for changes.
Without sorting out these details, the site would still load, but maintaining it over time would be a mess.
AI is more like someone who keeps asking questions
After this week, I see working with AI in more practical terms.
It doesn't just generate code for me, and it doesn't always get things right on the first try. Where it really helps is turning a vague problem into steps with me: check where things stand, define the boundaries, write the plan, then verify the result.
Of course I hit some snags along the way. How does the production environment relate to my local one? Did the remote device actually register? Will the scheduled jobs mess with the new site? You can't solve any of these with one prompt. You have to check them again and again.
That's exactly why building in public is worth writing about. It's not about showing off a polished result. It's about recording how a product slowly finds some order in the chaos.
If you're also using AI to build a product or project, drop a comment. What do you want AI to help with most right now: writing code, or working through complicated problems?