When “impossible” means we haven’t broken it down yet
A feature often arrives as one package, even though its parts are needed at different times. Finding those gaps can turn an impossible delivery into a sequence of smaller releases.
I learned that when I had three weeks to deliver two major features for a contract that could keep the company afloat. The first reaction on the call was reasonable: this is probably impossible.
By the end of the project, the work felt manageable. The technology didn’t get simpler. I discovered that the deadline we were discussing wasn’t the deadline for everything.
The company grew quickly during COVID. Its product let organizations set up location check-ins with their own terms, questions, and health checks. Someone scanned a QR code, completed the check-in on their phone, and received a confirmation token to get in.
That worked well while health screening and liability concerns were driving new business. Then contracts started drying up. Most developers moved to sister companies. I stayed, working directly with the CEO, CTO, and sales team, mostly on my own, with occasional help from a part-timer.
A sales rep brought us a potential contract with an events organization. They needed two things the product didn’t have: staged check-ins and email invitations.
Their flow would start with a pre-check-in, continue with the main check-in at the event, and finish with a post-event survey. Invitations had to go out beforehand so attendees could complete the first stage before arriving.
We had three weeks until customer onboarding. In the initial call with leadership and sales, the whole thing sounded overwhelming. I asked to dig into the details before committing either way.
I built a Figma prototype of the staged flow and invitation setup so the sales rep could validate the changes with the customer before we committed to building them.
On a follow-up call with the sales rep, I found the detail that changed the project: onboarding was in three weeks, but the event wasn’t happening until week five.
Those dates had been treated as one big requirement. They weren’t. The customer needed to configure the event and invitations during onboarding, but the complete check-in flow wasn’t needed until people actually used it.
That gave us a release plan. First, I built the invitation setup and enough of the new interface for the customer to prepare everything. The parts that weren’t ready showed a “coming soon” screen. They could configure the event without us pretending the whole flow already worked.
Once the prototype checked out, I started with email delivery.
The app was a conventional Rails application on Heroku, with server-rendered interfaces, Sidekiq, Redis, and Action Cable. We used Postmark for email. It was a comfortable setup for moving quickly, but email deliverability was still the risk I worried about most.
We had never sent invitations like this before. I configured Postmark, handled domain verification and environment settings, and tested delivery ahead of the event. It was an important event, and I didn’t want to discover an email problem at the last moment.
The staged check-in also had to work for people who ignored the invitation. If someone completed pre-check-in, the main check-in could skip those questions and get them through faster. If they arrived without doing it, scanning the QR code took them through pre-check-in first and then straight into the main flow. Nobody had to know there were separate features behind the scenes.
During onboarding and the event, I monitored the new pages and checked our Heroku scaling limits. I adjusted the concurrency caps so the app could spawn enough instances under load.
Then it worked. The invitations went out, onboarding went fine, and the event went fine too. There was no dramatic launch-day save. I mostly watched things behave the way they were supposed to.
The customer stayed with the company. I left a few months later for unrelated reasons, and when the company approached me again more than a year later, that partnership was still going.
The experience changed how I look at feature requests. Sales reps, project managers, and customers usually describe a feature as one package. But even a simple feature contains actions that happen at different times.
Those gaps are opportunities. If you can find when each capability is actually needed, you can turn one intimidating delivery into a sequence of smaller, useful releases.
The deadline didn’t move. My understanding of it did.