How to Ship in Two Weeks When There Is No Other Option

Most projects have a runway. Weeks of discovery, requirements gathering, design reviews, stakeholder sign-offs. The machinery of delivery running at its normal pace.

And then sometimes, the machine breaks. An external event collapses the timeline. The business need is immediate and the option to move slowly doesn't exist. You have to ship — now — and figure out the rest later.

In March 2020, that was my reality.

The situation

The City of Edmonton's Muttart Conservatory had a thriving plant shop. Citizens came in, picked their plants, paid at the till, went home. Then COVID-19 hit and the facility closed to the public overnight. No in-person sales. No transition period. The revenue stream — and the service to citizens who depended on it — simply stopped.

There was already an attempted solution in place. Someone had tried to adapt the city's existing CRM to handle online orders. It went live. It didn't work. No real-time inventory, no automated order management, staff doing manual reconciliation around the clock just to keep up. It was costing more to operate than it was generating.

I had two weeks to fix it.

Decision one: don't build, integrate

The single most important decision I made in the first hour was this: I am not going to build anything from scratch.

When time is the constraint, custom development is almost always the wrong answer. Custom development requires requirements gathering, architecture decisions, build time, testing, deployment infrastructure, and debugging in production. All of that takes weeks at minimum. We didn't have weeks.

What we needed was a platform that already solved the problem — e-commerce with real-time inventory — and that I could configure and launch in days. Shopify was the answer. It wasn't a compromise. It was the correct tool for the job, chosen under the constraint of time.

This is the decision most people in a crisis get wrong. The pressure to do something often translates into the pressure to build something. Resist it. The question isn't "what can we build?" The question is "what already exists that solves this?"

Decision two: scope ruthlessly

Two weeks is not enough time to build everything anyone might want. It is enough time to build the thing that solves the core problem.

I defined the minimum viable outcome: citizens can purchase plants online, inventory is tracked in real time so we never oversell, and there is a curbside pickup option for people who are used to visiting in person.

Everything else — advanced analytics, loyalty programs, custom design, multiple payment methods, French-language optimization — went into a backlog. Not forever. Just not now.

Ruthless scoping is uncomfortable because it requires saying no to people with legitimate needs. But it is the only way to ship on a deadline that cannot move.

Decision three: communicate before you're ready

On day three, before anything was built, I briefed the stakeholders on exactly what we were going to deliver, what we were explicitly not delivering in this phase, and why. I showed them the Shopify plan. I explained the curbside pickup workflow on a whiteboard.

There were questions. There were requests to add things. I documented every request and pushed them to phase two. Then I went back to building.

This matters because in a crisis, the absence of communication creates anxiety, and anxiety creates interference. Stakeholders who don't know what's happening start asking questions at the worst possible moments, calling meetings, requesting updates. Briefing them early — even when you don't have all the answers — buys you the space to execute.

Decision four: test with real users, not yourself

On day ten, I had the core system running. Before going live, I asked three staff members — people who would actually use it — to run through the purchase and pickup flow as if they were citizens.

They found things I hadn't thought of. Not bugs in the traditional sense, but gaps in the experience. Unclear pickup instructions. A confirmation email that didn't tell citizens what to bring to collect their order. A product description format that didn't translate well to online shopping.

I fixed all of it in two days. Not because I had time to spare, but because launching with those gaps would have created a support burden that would have consumed more time than fixing them before launch.

What we launched

On day fourteen, the Muttart online store went live on Shopify. Real-time inventory. Automated order confirmation. Curbside pickup booking with clear instructions. Home delivery option.

The overtime stopped. Citizens could shop. The revenue stream resumed. Staff went from spending their days reconciling spreadsheets to fulfilling orders.

What this framework looks like in any crisis

1. Don't build — find what already exists. Custom development is a last resort under time pressure, not a first instinct.
2. Define the minimum viable outcome, not the ideal outcome. Ship the thing that solves the core problem. Everything else is phase two.
3. Communicate before you're ready. Brief stakeholders early. Push all additions to a documented backlog. Protect your execution time.
4. Test with real users before launch. Not QA. Real people who will actually use the thing.
5. Launch, then iterate. A live system that's 80% right is worth more than a perfect system that ships in three months.

The constraint of two weeks didn't produce a worse outcome. In some ways, it produced a better one — because there was no time for committee debates, no room for scope creep, and no opportunity to overthink decisions that needed to be made and moved past.

Pressure, handled correctly, is clarifying.