A few months ago, I shipped a full Travel Log app with ChatGPT 5.5 + Codex. It worked. I used it on a real trip. Then I built a billing/invoicing tool with Grok Build in roughly two hours. That second experience changed how I work.
I’m now moving every internal tool and client prototype (new and old) over to Grok Build. The latest one is a Tax Prep and review app I needed for submitting accounts to the CPA. Here’s why the switch happened, what the new app actually does, and the practical limits I ran into.
The SpaceX angle (yes, it matters)
I own SpaceX stock. That is not the only reason I switched, but it is a real one. When the same company that is iterating Starship is also shipping the coding agent I use every day, the incentive alignment is hard to ignore. Grok Build sits inside that stack. I would rather put my daily tooling and my capital on the same trajectory than keep hopping between vendors whose incentives are purely short-term token revenue.
The technical reasons mattered more, but the ownership made the decision cleaner.
What changed between the Travel app and everything after
The Travel Planner was classic vibe coding: write a PRD, feed it to ChatGPT 5.5, iterate with precise prompts, test heavily, deploy. It took a focused weekend plus later polish. It proved the pattern works.
Grok Build is a different loop. Terminal agent + Plan Mode + subagents + multi-file edits in one session. It keeps project context, proposes a plan you can approve or adjust, then executes across the codebase without the constant “here’s the next file” hand-holding. For operational tools that need to talk to the real filesystem, PDFs, Excel, local services, and shared storage, that difference is decisive.
I no longer start with “generate the whole app.” I start with the real problem, the real data locations, and the real constraints, then let the agent drive the implementation under supervision.
The latest app: Tax Prep and review
I needed something that could:
-
Ingest company bank-statement PDFs from multiple banks. Some of the banks in use had only printed statements.
-
OCR the pages where a download is not available
-
Parse transactions into clean rows
-
Let a human categorize (Rent, Deposit, Fee, Other + custom categories)
-
Exclude noise
-
Export a CPA-ready Excel workbook with totals, net, and a By Category sheet
-
Support multiple companies
-
Be usable by more than one person without standing up a real backend or auth system
The result is a local browser app served by a small Python HTTP server. You open it on the LAN, pick a company, save PDFs to OneDrive, review/edit categories, then export. The spreadsheet lands in the shared output folder ready for the accountant. And this can be done each month so there is not a ton of work to get the info to the CPA after year end.
Making it multi-user without a real multi-user backend
The interesting part for a solo consultant or small team is the collaboration model:
-
All statement PDFs live under a shared OneDrive for Business tree (Bank Statements\<Company>\*.pdf)
-
All categorized data, company index, and category lists live in a shared app-data folder inside the same OneDrive library
-
Each person runs the app locally on their own machine and points their config.json at their synced paths
-
Exports go back into the same shared tree so everyone sees the latest spreadsheet
No Graph API calls. No custom sync service. Just the OneDrive sync client doing what it already does, plus a local web server that only accepts private/LAN addresses by default. OCR and parsing stay local. Grok Build picked the tools to do the OCR. Results land in the shared folder and propagate.
I’ll be doing more security work to lock down risks later. But reviewing security bottom line: The app is appropriate for a small, trusted team on a private network, but any client on the allowlisted LAN is a full admin over bank data, check images, exports, and invoices. The largest gaps are no auth, filesystem browse/register, and financial data over clear HTTP, not a single exotic RCE in the OCR pipeline. I’ll resolve those issues shortly and update this blog.
That design matched the actual constraint: a trusted internal team that already lives in OneDrive for Business, not a public SaaS product. The code is backed up to a private GitHub repository, and the data is backed up in OneDrive.
Limits and issues (the honest section)
This approach is not magic. The real constraints showed up quickly:
-
OneDrive sync lag — After someone drops new PDFs or exports a spreadsheet, everyone else has to wait for the client to finish. Files On-Demand is fine, but the files must be available locally when you OCR.
-
Concurrent edits — Two people editing the same company data at the same time can produce OneDrive conflict copies (filename-ComputerName.json). We treat it as one active editor per company at a time, or we coordinate.
-
OCR quality — Scanned statements are imperfect. The parser is tuned for the bank layouts we have, but every import still needs human review. That is by design; the app never pretends the OCR, scan and classification is authoritative.
-
Local compute — OCR is CPU-bound on each machine. Large batches of multi-page PDFs take time. There is no cloud OCR path. Running 7 months of data take about 10 minutes. But that’s time the computer is working while the team can do other tasks.
-
Security model — The server is LAN-only by default (private IP ranges only). Public internet clients get 403. That is intentional. This is not something you expose to the open internet without additional controls. Also, there is no path to the HTTP server via the firewall.
-
No real multi-user locking or auth — Shared folders + local servers is simple and works for a small, trusted team. It is not a replacement for proper multi-tenant software with concurrency control.
None of these are surprises. They are the trade-offs you accept when you prioritize speed of delivery and zero new infrastructure over enterprise-grade collaboration features.
Converting the old OpenAI apps
I also had Grok Build convert my earlier OpenAI-built apps over to the Grok Build workflow. That conversion step took roughly 5–10 minutes per app. After the Travel Log was converted, I continued making updates to it under Grok Build, tested the changes, and pushed them live to travel.jdb.net with no friction. The transition was clean enough that I no longer keep a separate OpenAI toolchain for those projects.
Why this is now the default stack
Grok Build’s Plan Mode + subagents let me describe the full system (PDF ingest → OCR → parse → categorize UI → Excel export → shared OneDrive layout → LAN-only server) and get a coherent multi-file result instead of a pile of disconnected snippets. The previous ChatGPT + Codex workflow required more manual glue and more context resets.
For internal tools that have to touch real files, real PDFs, real Excel, and shared team storage, the terminal agent approach is simply faster and more reliable in my hands. I still write the requirements and still own the architecture and security decisions. The agent just removes most of the typing and the file-by-file thrash.
The Tax Prep app is at least as complicated as the Travel App was. But Grok Build let me build it, have the team test it and make sure it was had limited multi-user function in about 4 hours. That’s less than ½ the time it took to build the initial Travel App. As the Travel App was my 1st Vibe Coding experience, there was probable 10%-20% waisted time but for me Grok Build is the way forward for now. Check back to see if I change my mind in the future.
I am not claiming this is the only way, or that it replaces traditional engineering for every problem. For the class of tools I actually ship for myself and for clients—operational apps that need to be correct, reviewable, and in production the same week—the switch has already paid for itself.