How Constraints Shaped a Storefront Under Pressure

Picture this: two software engineers and one month. What can actually be accomplished with those constraints?

Back in the late summer of 2024, I was tasked, along with one of my coworkers, to stand up a storefront for a warehouse sale powered by BigCommerce. We had four weeks to get it into a purchase-ready state, soft-launch it internally, and be ready for a public launch ten days later.

We immediately had some questions. What absolutely had to work on day one? What could we offload onto BigCommerce? What failures would directly block revenue? What did we not have time to build safely?

This is how two engineers stood up a storefront for a sale site within a month that generated seven figures in revenue within the first two weeks of public traffic.

We didn't do this with the perfect tech stack, a giant team, full process, or a polished architecture. Instead, we made early decisions about scope, ownership, and risk, then reacted quickly when real usage showed us where weaker spots were.

Constraints

Before coding started, the project already had a base shape. At this point, we had a few constants: a small team, a fixed launch date, third-party systems we would work with, and little room for feature expansion.

There were a few noteworthy things we knowingly skipped for this project:

• a test suite
• load testing
• error tracking
• mature observability
• a formal design handoff

That kind of honesty matters much more in the beginning than most engineers realize. Projects fail not because the tools weren't the right tools, but because a small team agrees to take on too much, too early, without enough feedback loops to know what's going wrong.

I learned something important: don't just decide what you will build, but what you won't build before you start building.

Scope

Architecture isn't just about frameworks, rendering strategies, and infrastructure. I'd argue a more important part, especially in the beginning, is what parts of a system actually belong to me.

This storefront wasn't going to be a long-running commerce site. It was a short-lived sale site with a strict deadline with a narrow purpose: show products clearly, maintain the purchase flow, and get customers to checkout without friction.

We had an internal rule: if this feature wouldn't help to launch the site or get the user to checkout faster, it wasn't needed.

This included skipping a custom checkout, account system, CMS, and a wish-list. Extra layers of abstraction to make the codebase feel more robust were not justified.

I don't want to pretend this is how most projects should be built. Given more time, I would have set up a more durable system. But this is risk management. Every feature we didn't own was one less thing that could fail under pressure.

Tools

Setting boundaries made deciding on the tech stack easier.

We picked tools both of us could move quickly in. This mattered more than choosing the day's recommended stack from the debates on tech-Twitter/X. Under a short deadline, familiarity compounds. You'd spend less time fighting your tooling, make fewer mistakes, and keep most of your attention on the arts of the system that would cost you revenue.

Astro was a strong fit for a few reasons. It let us build the storefront mostly as a static-first site, while still giving us room for specific server-rendered pages and isolated client-side interactivity where it was needed. BigCommerce handled the heavy and commerce primitives that would have been impossible for a two-person team to create given our timeframe. Even then, we had to stay pragmatic: the GraphQL APIs didn't always return the product data we needed, so we mixed in REST for parts of the product detail page, cart flows, and inventory work instead of forcing the project through a refactor to maintain one integration model.

The infrastructure matched that mindset too: a small deployment footprint on a single DigitalOcean droplet managed through Cleavr, Astro for the storefront shell, and Svelte 5 for interactive surfaces that actually needed client-side behavior.

This combination gave us a useful default: purity would have slowed us down. Correctness mattered more.

Complexity

The whole site wasn't engineered without any complexity. Instead of avoiding it, we isolated it.

Certain parts of the site, namely the cart behavior, search, inventory visibility, and order information, demanded more care than other parts of the storefront. We discovered a bug during our internal launch where the cart and session did not persist correctly. This was the exact kind of failure we wanted to catch before public traffic arrived.

This was a second lesson I learned: good architecture under pressure isn't about making every layer look clean. It's about knowing where simplicity is safe, where it's unavoidable, and where the business will absolutely notice if you get it wrong.

Perfection

"This was a perfect project" are the words that don't describe the result of our efforts. There were obvious gaps, and the biggest one was skipping error tracking from day one. Once traffic arrived, some issues reached us through word-of-mouth first, and triage often meant digging through the logs manual instead of having a clear picture of where the failures happened.

This doesn't mean that the work was careless. It means we had to sequence quality. One of the ways was by using the launch structure itself as a testing tool.

We had two launches. After four weeks of work, we soft-launched the site internally for employees. Ten days later, we opened it to the public. A so-called "perfect project" may have been able to get away with just one. The first launch was deliberate: it gave us access to a friendly group of testers who surfaced issues from a real customer flow, especially around cart and session persistence, before actual customers saw them.

Our public exposed a different kind of pressure. Our warehouse inventory integration depended on a third-party API, and once we saw +250k visitors within the first 24 hours, the cost of those calls grew fast. We fixed that by adding a Redis cache with a scheduled refresh which cut the API costs by roughly half. This issue deserves its own write-up in the future, and is another reminder that some problems only become visible once the system is under real use.

There's a big difference between ignoring quality and sequencing quality. On small teams with deadlines, that distinction matters.

Lessons

The technology pick was important, but it wasn't the main lesson I learned.

The larger lesson was that constraints force clarity, only if you listen to them. We had to decide what kind of system we were actually building, where to offload work, and where we needed to spend our own time engineering.

That's what matters to me most. Not how we built it, but how we made the decisions that let two engineers ship something meaningful in a short amount of time.