We Shipped a Feature in 7 Days: An Engineering Manager’s POV

The last quarter of last year – at Solflare – was easily one of the most intense and exhilarating periods of my career. We were navigating a sea of critical deadlines and the high-pressure buildup to the Solana Breakpoint conference. 

But amidst the chaos, one challenge stood out. We took on a project that can make or break a team: delivering a major feature in 7 (seven!) days. This was a feat that, under our standard process, I would have predicted to last for 30 days.

Hint, hint, you’ve likely guessed the feature: Prediction Markets.

As an Engineering Manager, I was once again reminded about the core truth: competitive market pressure sometimes demands an immediate response that skips the “standard” playbook. In these moments, good leadership isn’t about enforcing the rules. It’s about knowing which ones to break to unlock a new level of velocity.

In a startup, being first to market can grant a massive competitive edge. However, everything in product development is a tradeoff. We often refer to the “Priority Triangle” – the constant tension between Speed, Scope, and Quality.

This Wasn’t On Our Roadmap…

When Prediction Markets began to overwhelm the crypto community, it wasn’t initially on our roadmap. We were focused on Breakpoint. But once we saw the signal, we had to act. To decide if we should enter “Crisis Mode” (or Code Red), we ran the team through a three-point check:

1. The Market Signal: We didn’t need a deep-dive analysis to see where all the noise was. The activity on other platforms made the demand obvious.
2. The MVP Scope: Can we define a minimum version that provides real value without being “trash”? Our goal was simple: enable users to trade. We prioritized pure functionality over visual polish.
3. The High Trust Team: Do we have the right developers and designers who can work in a high-bandwidth, low-process environment? The criteria here were simple: I needed volunteers for this initiative – people who know what they are signing up for. We looked for people capable of maintaining speed without sacrificing caution in a no-process environment, and they should be willing to commit to the crunch of longer hours.

Once we hit the “go” button, my role shifted. I became a shield.

I gathered a small strike team: 

• 2 frontend developers,
• Backend developer,
• Designer
• …and QA. 

My job was to clear the path. I canceled every meeting, blocked every external distraction, and gave them one directive: Develop and break the rules… our rules.

Done With Our Definition of Done

To hit a 7-day (yes, 7-day deadline!) deadline, we intentionally dismantled our “Definition of Done.”

• The Huddle over the Ticket: We abandoned the ticket management system. Instead, developers lived in an eight-hour Slack Huddle. They synced in real time, effectively performing “live” code reviews as they pushed to a single shared branch. For example, if a frontend dev hit a block with an API response, they didn’t open a ticket; they would immediately communicate with the backend engineer, who would patch it on the spot.
• Threads as Truth: We didn’t wait for formal specifications. Slack threads became our documentation. Product requirements, backend logic, and UI tweaks lived in fast-moving threads. While not scalable long-term, it worked perfectly while everyone’s “context window” was wide open for that one week.
• Risk Acceptance: As the EM, I signed off on the risk. We knew bugs might slip through. By explicitly accepting that responsibility, I provided the psychological safety the team needed to move fast without the fear of being blamed for imperfections. The focus was on critical path stability – if a few pixels were off here and there, we left it for later.

Setting a team on a path is only a start. As you know, you cannot drive a car in 6th gear without monitoring the engine. During this high-pressure week, my primary job was managing energy.

• The Micro-Feedback Loop: When you’re in a 14-hour-a-day grind, silence is the enemy. I made sure every win was visible, whether it was a quick Slack reaction to a bug fix or a public shout-out in the company-wide channel.
• Verbalizing the “Extraordinary”: I had individual conversations with each team member to explicitly frame their work as an outlier performance. By being transparent about how this effort translates into their career growth, I removed the ambiguity that can lead to resentment.
• Cool Down: We made clear with the team that after this delivery, we will slow down. That way, they knew that they would have time to recover for any extra push they did now.

Don’t Touch… Anything!

After the party, you need to clean up. The danger of “Crisis Mode” is that it creates technical and organizational debt. If you don’t pay it back, your codebase will rot. The worst-case scenario is that the hacks we implemented in one week become “baked in.” The logic can be so tangled that fixing one bug creates three more. And as a result, the team can become afraid to touch the code.

So, immediately after the Predictions Market went live, we entered Debt Collection:

• Retroactive Documentation: We turned our chaotic Slack threads into formal technical and product specs so the knowledge wasn’t lost. We created functional specification documents that describe the feature behavior and technical specification documents that describe tech details like client-to-backend communication.
• Refactoring the “Hack”: We scheduled time to clean up the “just make it work” code before it could become a permanent nightmare. Every time we started adding something new, we allocated extra time to clean something up. The rule was simple: If you touch something, leave it better than you found it. By doing it that way, we didn’t just stop evolving the feature, and cleanup happened during feature development.
• Managing Expectations: I had to communicate clearly to stakeholders that this “Emergency Gear” was for one-time use – or at least not something to be expected on a monthly basis. We cannot make “one week features” our new standard without burning the team out and destroying our architecture. That meant that output and the amount of updates we were releasing would slow down, but the feature would become more polished.

High velocity is a tool you deploy, not a permanent state of existence. By breaking the rules for one week, we didn’t just ship a feature – we proved our team’s agility. A good side effect was a big morale boost.

Now, in 2026, our focus has returned to improving how we do things. We are iterating on our processes not just to be faster, but to ensure that when the next “Code Red” moment arrives, our foundation is strong enough to handle the heat.

Reflecting on that very, very intense period, I feel incredibly bullish on our team. We’ve shown that we are not a one-speed engine. We can operate with precision during standard sprints, but also pivot into a high-velocity strike team when the market demands it. That kind of versatility is rare, and it’s exactly what we’ll need to navigate this – and upcoming years.