Early in my career I estimated “add a chatbot” like a theme section: a handful of hours, a happy path, a tidy invoice. Then production arrived — retries, empty retrieval, admin UI for the policy docs, a feed that updated at 2 a.m., and a merchant asking why the billable hours were already gone.
Six-plus years and fifty-plus projects later, the lesson is sticky: estimate in systems, not hours. Price the pipeline — retries, feed, admin UI — not the demo that works on localhost with three SKUs.
Hours measure effort. Systems measure reality.
Hours answers “how long will you type?” Systems answers “what has to keep working when we leave?”
A Shopify metafield migration estimated in hours looks like scripts and imports. Estimated as a system it includes:
- Mapping sheet + validation
- Dry run on staging
- Rollback / undo story
- Merchant training for the new fields
- What happens when the vendor feed adds a column next month
- Who owns the metafield definitions after launch
MetaGrid and BulkFix exist because the “hours” version of metafield editing never matched the system merchants actually needed. The spreadsheet mental model won because the system was bigger than a one-off script.
The happy path is a liar
Demos are optimized for applause:
- Perfect sample data
- No rate limits
- One language
- One currency
- The CEO’s favorite SKU
Production is the opposite. When I scope from Karachi for clients in other timezones, I explicitly ask for the ugly cases first: partial refunds, bundles, legacy SKUs, bilingual policies, apps that already mutate checkout.
If the estimate only covers the applause path, it is not an estimate. It is marketing. I would rather walk into a kickoff with a longer list and a calmer merchant than a short list and a surprise change order.
What I put in a system-shaped estimate
For AI features, the system usually includes:
- Ingestion — docs, catalog, metafields, who updates them
- Retrieval or context assembly — chunking, refresh, empty behavior
- Generation — model tier, schemas, output caps
- Tooling — order lookup, tickets, Slack handoff
- Guardrails — refuse-when-empty, PII logging rules
- Admin UX — how non-developers update prompts or content
- Observability — traces, cost dashboards, eval set
- Failure modes — retries, queues, degraded UX
For Shopify theme or custom feature work:
- Design states (empty, error, loading, multi-market)
- App interactions and script budget
- Metafield/metaobject model
- Content editor workflow
- Performance budget on mobile
- QA across the markets you actually sell to
- Handoff notes for whoever maintains it next
Same discipline. Different checklist. If a bullet has no owner, it is not scoped — it is wishful thinking.
Pricing the meter, not the myth
AI makes underestimation worse because the demo is free and the meter is not. I put token math and a 3×-demo stress case in proposals. Merchants can poke the AI API cost calculator themselves. For automation ROI, the agent ROI calculator keeps “hours saved” honest. For storefront builds, the Shopify build cost estimator frames theme vs custom vs apps as a system choice.
I would rather lose a deal on a clear ceiling than win one on a fantasy hour count. Clear ceilings also make handoffs across timezones easier: the merchant knows what “done” means without me being online.
A worked contrast (no fake client metrics)
Hours-shaped: “Support bot — 20 hours — wire OpenAI, add widget.”
System-shaped:
- Widget + brand styling + mobile QA
- Policy ingestion + weekly refresh
- Order-status tool (read-only) + failure copy
- Handoff to Slack/helpdesk with transcript
- Redacted logging + 30-day retention
- Prompt versions + a 30-question golden set
- Cost ceiling and model routing defaults
- Two weeks of hypercare overlap across timezones
The second list is longer. It is also the work. Merchants who have been burned recognize themselves in it. Merchants who have not yet been burned need to see it once before production teaches them the expensive way.
You can still phase it. v1 might skip auto-refunds and fancy analytics. Phasing is honest. Pretending those pieces are free is not.
How I talk about uncertainty
Systems estimates still have ranges. I use ranges on purpose:
- Build effort as a band (discovery may reveal two extra apps fighting the theme)
- Monthly AI variable cost as a band tied to volume assumptions
- Explicit exclusions (“we are not automating refunds in v1”)
- Dependencies on merchant tasks (content cleanup, policy rewrites)
Uncertainty belongs on the page. Hidden uncertainty becomes discord arguments later — usually at an inconvenient hour for someone.
Habits that keep estimates honest
- Write the failure modes before the feature list
- Include an admin path for whatever content the model needs
- Assume feeds break; say who gets the alert
- Budget QA on real devices and real catalogs
- Add hypercare across timezone gaps — async handoff is part of delivery from Karachi
- Re-estimate when scope adds a write capability (refunds, address changes)
- Separate build cost from monthly run cost so nobody confuses them
When someone says “just estimate the happy path and we will see,” I translate: “please underbid.” I decline politely or I reframe into a discovery spike with a fixed small fee.
Why this is a Playbook lesson, not a rate-card flex
This is not about charging more for sport. It is about shipping systems that do not melt on week two. The products I build — MetaGrid, BulkFix, VisaChamp, these calculators — all came from systems that were under-served by hour-shaped thinking. Spreadsheet metafield edits, visa document QA, API cost whiteboards: each needed a durable loop, not a one-off script.
Client delivery taught me the loops. Products made the loops reusable. Estimating in systems is how both stay viable.
Discovery spikes are systems too
When unknowns dominate — weird ERP, three overlapping apps, unclear policy ownership — I sell a fixed-scope discovery spike instead of a fake firm estimate.
A spike still has a system shape: questions to answer, artifacts to produce (diagram, risk list, revised estimate), and a hard time box. The output is clarity, not production code. Merchants who want only a number before discovery are asking you to guess. Guessing is how hour-shaped pain begins.
Try this on your next proposal
Replace the line “Feature X — N hours” with:
- Inputs that must stay fresh
- Outputs someone will trust
- Human escape hatch
- Ops UI
- Observability
- Monthly variable cost ceiling
- What v1 explicitly will not do
If you cannot fill those bullets, you are not ready to estimate. Do a short discovery spike instead — still a system, just a smaller one.
I am Faraz Hussain — Shopify developer and AI automation consultant in Karachi. If you want help turning “add AI” or “small Shopify tweak” into a scoped system with a real ceiling, that is the work. Use the calculators on this Playbook to pressure-test the variable costs while we pressure-test the pipeline.