How I ship
I run a one-person studio that ships production software with a team of AI agents under a written method: every project has a case file, every change is verified against the real system, and every week ends with a report of what changed and how long it took. Strategy and execution in the same loop.
What is running today
Measured on the server on October 4 (weekly inventory) and October 10, 2026. One edge, one method, every app in its own container with its own database.
Apps in production: a custom e-commerce storefront, admin and API (Arca Tierra); a PWA for event planners (Messy Tables); an arcade hub with replay-verified leaderboards (estom.mx); a client portal with hours per phase (dashboard.dabychos.com); ten single-page product demos (demos.dabychos.com); and smaller apps with real users.
The loop every project goes through
In your vocabulary
| You say (your website) | What I do | Evidence |
|---|---|---|
| "Strategic rigor and execution velocity" | A case file per project and a build loop with agents: the strategy is a document the client approves; the execution is the next phase, already scoped. | Client portal with phases and hoursdashboard.dabychos.com |
| "Measurable outcomes in 60–90 days" | A weekly log of every change, verified against git and the database, with real time per fix. The client sees hours per phase, not a promise. | Weekly work log and hours reportgenerated every Monday |
| "Guardrails", "human-in-the-loop" | Agents cannot delete or overwrite anything that existed, touch curated memory or publish client data without an explicit OK. Builds without cache; the image is verified against the tested code before it goes live. | Written operating rules and a deploy checklistenforced by hooks, not by memory |
| "No pilot purgatory" | A demo in 24 hours, isolated per client, with login, daily backup and a reminder at 90 days; nothing is deleted automatically. | Demo mold and publishing scriptdemos.dabychos.com |
| "Platform-agnostic" | Everything is a container with its own compose file behind one edge; nothing depends on a vendor dashboard. | 58 containers, 34 public hostnames, one edgedocker ps and Traefik · 10-oct |
| "Sprint-based execution" | Phases with gates: the client approves from the phone before the next phase starts. This very preparation ran on that method, with three gates. | Plan page with gates and approvalsOctober 9–13, 2026 |
What I would not claim
Said plainly
- I had not built on Shopify before this weekend. My platform work is custom e-commerce; what I did this weekend is read the 2026 docs, the staff threads and the CLI issues, and build against them.
- The hours behind this server are mostly agent hours. My own are in the hundreds, not thousands. That ratio is the point.
- I am not a senior by years of continuous coding. I am a mechatronics engineer who ran a construction company for eleven years, moved to software with a custom e-commerce platform, and built a method that lets one person run what you see above.
What that buys you
- A second pair of hands that already knows the migration, without a long ramp-up: the method, the QA and the monitoring come with me.
- Written scope and written results: what I will do, what I will not, and what happened each week.
- Your lead developer stays the owner. I take the queue behind him: audits, embeds, price lists, tests, documentation.
The two-minute video
Screen recordings only, no audio, no client data on screen (demo stores and test accounts). The storyboard is final; the recording is available on request.
What I built for this conversation
Built this weekend on public information and my own development store. Nothing of yours was touched, and no app of yours was installed.
settings_data.json parsing, deep link by theme ID, queue backoff, combined verdict, price-list plan and batchingscriptTagCreate refused on 2026-10, 2026-01 and 2025-10, verbatim, on a development storeLive proof, from Shopify itself
"This app can't create or update script tags. Use theme app extensions instead."
The kit has a button that asks Shopify to create a script tag and shows this refusal live. It runs with expiring offline tokens, so the January 1, 2027 token change is already covered.
Script-tag migration kit built
A Shopify app with a theme app embed (country selector on Shopify Markets, no JavaScript price conversion) and four stages per store: measure the legacy code, open the activation by theme ID, verify with three signals (theme settings, app.extensions() and a beacon from the storefront), then remove one store at a time with backoff. It says up front what no app can do: switch the embed on for the merchant, rewrite theme code, or reach frozen stores. It also moves per-country variant prices to a Markets price list per market, up to 250 prices per call, audited with what Shopify will really charge.
Migration playbook, 2026 edition ready
Three dates, not two; the four official steps with the parts the docs don't say out loud; what a kit can and cannot do; a six-step plan for storefront apps.
What your merchants ask for ready
1,873 public reviews read as a product: what they praise first, seven recurring frictions with counts, and why the first one, theme-dependent code, is the same problem the kit solves. No merchant or support-agent names.
Prepared by David Abraham Aguilar (DabyChos Studio, Mérida, Mexico) for the conversation with MLVeda on October 13, 2026. All numbers measured on the studio's own server; no client data, no credentials and no customer records appear on this page or in the video. Private page: shared on request.