From vague idea to a portal in production

When the team first reached out, they had urgency but not clarity. A launch date was already on the calendar — not because the scope was locked, but because a business commitment had already been made to leadership, to a market window that wasn't going to wait for a perfect brief. What they had was a rough idea of a customer portal: something that would let their customers self-serve instead of calling in for every update, but no wireframes, no technical spec, and no shared internal agreement on what "done" actually meant. Different people on their team had different mental pictures of the same project.

That's a more common starting point than people admit, and it's also a genuinely risky one. Teams in that position tend to do one of two things: freeze while they wait for a brief that never quite arrives, burning the very weeks they can't afford to lose, or start building against a guess and discover three sprints in that half the work doesn't match what the business actually needed. Neither option is really available when the deadline is fixed and non-negotiable. The only way through is to compress the "figuring out what we're building" phase without skipping it.

So that's where we started, immediately, without waiting for a finished spec to land in our inbox. Discovery meant structured working sessions with the people who actually knew the customer pain points, not just the people signing off on the contract — pinning down who the portal was really for, what the three or four things it absolutely had to do on day one were, and what could reasonably wait for a second phase. We wrote all of it down. Within the first week, the vague idea had become a product plan with real milestones attached — not a slide deck for a kickoff meeting, but a working document the team could hold us to for the rest of the engagement.

From there we moved straight into sprint-based development, with working demos every two weeks rather than a single reveal at the end. That mattered as much as the plan itself — a written scope only stays trustworthy if what gets built actually matches it, and the only way to prove that as you go is to keep showing working software, not screenshots or status updates. Each demo was also a checkpoint: a chance to catch a wrong assumption while it was still cheap to fix, rather than after launch.

The portal shipped inside the original deadline, and — more importantly — it's one customers actually use, which was the real test the vague idea had been pointing toward all along. The plan made in that first week held all the way to launch, and that's arguably the more unusual outcome: not that software got built on time, but that what got built on time was the right thing.