Forem: Benoit Doyon

From Vibe-Coded Seed to Agent-Assisted Engineering: Building a Feature at Flare

Benoit Doyon — Thu, 14 May 2026 18:48:05 +0000

A story about a banner, a Slack thread, and the two days between a vibe-coded prototype and a feature worth shipping.

The banner problem

A week ago Thursday, an AWS hiccup rippled into Flare. Customer-facing teams wanted a banner in the app, a calm sentence at the top of the screen letting users know we knew, and that we were on it.

We have a tool for this kind of thing. It's an in-app messaging product, the sort that lets non-engineers paint UX on top of a deployed app, and we use it well for the work it was built for: onboarding flows, feature announcements, product education. Improvised emergency banners are not that work.

The runbook agrees, sort of. The bulk of incident response is quick technical steps: declare the war room, announce, start the postmortem doc, mitigate. Then the communications part lands you at one item that links out to its own multi-page wiki article. An eight-step procedure in another product, with a screenshot for every step, ending with a reminder to disable the guide when the incident is over. The people with the right access weren't on the incident. We got the banner up anyway. It was not fast and it was not fun.

At Flare, working with Claude is just how engineers work. We use it for everything from one-line tweaks to multi-file refactors. That morning I picked the loosest possible mode of working with it: I vibe-coded the banner. Ten minutes, two merge requests open, a working banner on screen. I closed my laptop satisfied.

That banner never shipped.

This is the story of why, and of what showed up in its place. It's also a story about how the gap between vibe-coded experiments and production engineering is bigger than it looks, and how the right tooling makes that gap a lot cheaper to cross.

The seed

Here's what I built that morning. I have a coding agent in my editor. I described the problem out loud, something like "I want a banner at the top of the app whose text I can change from a checkbox in our admin tool," and we banged something out together.

We already had a feature-flag system. Feature flags have names and descriptions. The frontend already polled /me/profile for the current user's flags. I asked Claude to add the description field to the response, then to render a banner whenever a specific flag (outage_banner) was on, using its description as the message.

Two MRs, about 140 lines, working banner. Total elapsed time: about ten minutes.

This is what people mean by vibe coding. You hold the goal in your head, narrate the shape of it, and let the agent fill in the keystrokes. It is genuinely thrilling, especially for someone whose job description has lately involved more meetings than commits. Internally at Flare, a number of folks have started doing this with our newly-built experimentation infrastructure, and they're not wrong to be excited. Vibe coding is good at what it's good at: getting a real thing in front of a real person, fast.

The catch is what happens next.

The Slack thread

I posted the MR in our backend channel for a sanity check. The reply was civil and immediate. Over the next thirty minutes, it unwound the design completely.

The first thread: I was changing a public API. I argued, reasonably I thought, that customers don't read which feature flags they have activated. Alex agreed I could probably break the schema. Then he said:

However this is also a problem because this will leak internal descriptions to customers.

Our feature-flag descriptions, it turns out, contain employee names. It's a process thing: when you create a flag, you put your name on it. Mine, Xavier's, Alex's, everyone's. The cute hack of "just expose the description field" was, on closer inspection, a small employee-roster leak attached to every authenticated session.

The second thread: Xavier suggested side-stepping the whole thing: ping our public status page, show a generic message if it's not green. I'd been about to agree when Alex caught a different problem:

I don't think poking an external domain (status.flare.io) is a good idea in our app, this effectively leaks all our customers to Cronitor.

Our status page is hosted by a third party. Every customer browser pinging it from inside our app would have handed that third party a continuous record of who our customers are.

Two well-intentioned designs, two privacy issues neither of us would have caught alone.

The third thread, the one that actually changed the feature: Alex remembered something customer success had been asking about for a while. A per-customer banner. A way for a rep to put account-specific messaging into the app without coming to engineering each time. Not for incidents. For everyday communication with specific customers.

Suddenly the question wasn't "how do I show an outage message." It was: what shape does a system take that lets a customer-facing rep paint a top-of-app banner globally, per organization, or per tenant, without involving an engineer?

That feature already had a stakeholder, a justification, and a real reason to exist in a database table. The outage banner was just one case of it.

By the old rules, this is scope creep: don't build two features when you came to build one. But with an agent doing most of the typing, the cost of an extra table and an extra route is mostly the cost of deciding it should exist. The bottleneck has moved. The expensive part is figuring out the right shape, not writing the code. Bundling the outage banner with the per-customer ask wasn't more work, it was less work. The alternative was shipping a half-system now and reconciling it with a second half-system later.

I closed my laptop again. Not satisfied this time. Humbled by how much my ten-minute banner had been missing, but increasingly proud of what was taking shape in its place. This was no longer a quick hack.

The bloom

What happened next is what I want to show people, especially the colleagues who've been (justifiably) impatient with how long engineering takes once a vibe-coded prototype exists. Half the answer is in the section you just read. Engineers iterate on ideas before they iterate on code, and a working prototype hides that work without replacing it. Mine looked done. It had a security flaw, a privacy leak, and was missing an entire feature. None of those would have surfaced without other engineers pushing back on the design. The conversation was already engineering. The rest of this story, the specs and the MR stacks and the review, is how you ship it.

Step one: write the spec before writing the code

Before I touched a backend file, I wrote a spec. Not a slide deck, not a Confluence page. A Markdown file in our repo under docs/specs/, dated and titled, written with Claude in the same conversation where it had access to the codebase. It covered:

Data model: a new app_banners table with nullable organization_id and tenant_id. A check constraint preventing both from being set at once. Partial unique indexes enforcing one banner per scope.
Resolution rules: precedence is global, then tenant, then org, then none. A signed-in user sees at most one banner, and the resolver picks deterministically.
API surface: one public endpoint (GET /banner/current) that reads scope from the session and returns the resolved banner. One admin endpoint group for reps to set and clear them.
Frontend: where the banner mounts in the customer app, and where reps edit it inside our internal admin tool.
MR breakdown: how this was going to be cut into independently mergeable pieces.
Explicitly out of scope: scheduling, multiple concurrent banners. Listed by name, so they couldn't sneak in during review.

This spec took about thirty minutes to draft. It made every subsequent decision faster, and it gave reviewers a single object to argue with before any code was written. The conversation in Slack had surfaced the shape of the problem. The spec turned that shape into something committable.

Step two: stack the MRs

The spec called for four MRs:

Database table, model, store, and the read endpoint the customer app fetches
Admin endpoints to set and clear banners
Frontend that renders the banner in the customer app
Frontend for the internal admin tool where staff set the banners

Why four? Because each one needed to be a coherent, independently mergeable unit of value: small enough that a reviewer could reason about its safety in isolation, large enough that merging it actually delivered something. Stacked MRs (where each branches off the previous) give you that property. Every commit on the stack is a self-contained change, and each branch can be approved and merged as soon as the one below it lands.

This is where the agent earns its keep. Reading the spec, branching cleanly off the previous MR, writing the migrations, models, stores, resolvers, routes, tests, and frontend composables: that's hours of typing. Mechanical, but the kind of mechanical that gets sloppy when humans do it. The agent is patient and consistent in a way I genuinely am not after lunch.

What it isn't is the architect. The four-tier scope hierarchy, the precedence rule, the decision to keep the outage and per-org systems as one table rather than two: those came from the Slack conversation and from sitting with the problem for a while. Claude wrote the code that expressed those decisions. It did not make them.

Step three: let review do its job

The first round of review found that the admin endpoints had ballooned. The original spec called for six mutation endpoints (PUT /global, PUT /org, PUT /tenant, DELETE /global, DELETE /org, DELETE /tenant), each with their own handler, their own validation, their own audit-event payload. The reviewer's suggestion: collapse it to one PUT and one DELETE, with the scope expressed in the body and query string respectively. Half the surface area, fewer code paths, easier to test.

Another round of review pulled out comments. The agent had, like a slightly anxious junior engineer, sprinkled the diff with brief explanations of what each function did. The reviewer's note was simple: if removing the comment wouldn't confuse a future reader, don't write it. Down they came.

By the end, the feature was smaller than the spec it started from, and substantially smaller than a naïve translation of the spec into code. Each round of review made the implementation more focused, not just shorter. Fewer code paths, fewer special cases, fewer places a future reader has to look. That matters more now than it ever has. The next person to touch this code might be Claude, and a tight surface is one the agent can hold in context without dropping invariants. Code that humans can maintain easily turns out to be code that LLMs can maintain easily. None of those simplifications would have happened in a vibe-coding session, because there was no second pair of eyes. Review wasn't a checkbox. It was where the implementation got focused enough to be maintainable by whoever, or whatever, reads it next.

What this means for the rest of us

If you have been vibe coding experiments at Flare, please keep doing that. We built the infrastructure for it on purpose: custom tooling and workflows that provision a sandboxed machine, wire it into the data and systems an experiment needs, and hand you a place to try an idea without filing a ticket. The point of that investment was exactly to make experimentation cheap. Most of what gets built there will never need to become a production feature, and that's fine. Its job was to teach us something we couldn't have learned by talking about it.

But the moment a vibe-coded thing starts to feel like it might ship, you discover the gap between prototype and production. In our case the gap was about two days. Small enough to cross routinely, big enough to matter. What was in it:

The colleague who points out that the schema you thought was internal (say, a list of feature flags) is actually a roster of every engineer who has ever worked on the product.
The realization that a "harmless ping" to a third party reveals who your customers are, just by virtue of who's pinging it.
The product ask you didn't know existed: the one that turns your one-off outage banner into a feature another team has been waiting on for months.
The reviewer who notices that your six near-identical endpoints want to be two, because the difference between them is data, not behavior.
The reviewer who deletes the comments your agent added on autopilot, because they explain what the code does instead of why.

Engineering's job isn't to slow down the vibe-coded prototype. It's to take the prototype seriously, to hear it as a signal that there's a real problem worth solving, and to bring discipline to the design so that what we ship is something we'd be happy to point at six months from now. Agent-assisted engineering makes this dramatically cheaper. The agent does most of the typing, the spec carries the design pressure, and the MR stack carries the review pressure, leaving humans to do the part humans are good at: notice the things that aren't in the code yet.

What shipped, in the end, is a four-MR stack with tests, audit events, and per-org scoping. A customer success manager can now put a message in the app for one specific customer. A renewal reminder, a "heads up, we're migrating your tenant on Saturday," a "check out this new feature, it's right up your alley" nudge.

They did not get this in ten minutes. They got it in two days. Both numbers, I think, are correct.

Habits of Great Developers: The Underrated Power of Small, Frequent Merge Requests

Benoit Doyon — Tue, 10 Jun 2025 15:31:19 +0000

Trying to measure developer productivity is a famously difficult and often misguided effort. IBM’s historic attempt to gauge output by lines of code written is perhaps the most notorious example. It rewarded verbosity over clarity and activity over outcome.

Yet despite the limitations of rigid metrics, some patterns consistently emerge when you observe highly effective software engineers. At Flare, one habit we’ve seen repeatedly among our best developers is simple and powerful:

They make small and frequent merge requests.

In this post, we’ll unpack why this behavior works so well and how it supports better collaboration, faster iteration, and stronger product delivery.

Why Small, Frequent MRs Work

1. They Reflect Deep Understanding

At Flare, we work within a Shape Up-inspired product development framework. A large part of each cycle is spent on shaping and understanding the problem. By the time execution begins, the scope is usually de-risked and well understood.

When a developer has that deep understanding, they naturally break the work down into clear, manageable chunks. Each merge request becomes one of those chunks: focused, self-contained, and purposeful.

2. They’re Easier to Review and Safer to Ship

Large change sets are difficult to review thoroughly. Even experienced teammates can miss important details when too much is packed into a single MR. In contrast, small MRs:

Surface issues earlier
Make reviews faster and more focused
Reduce the risk of regressions
Are easier to revert if something goes wrong

This supports faster iteration and higher confidence in production releases.

3. They Encourage a Collaborative Mindset

A steady stream of small MRs creates rhythm in a team’s workflow. It encourages collaboration, builds trust, and makes progress visible.

Being stuck on something for too long, however, is a red flag. In one of the most effective teams I’ve worked with, we had a simple rule: if you were blocked for more than 40 minutes, raise a flag. That one principle saved days of frustration and kept momentum high.

What About Big Refactors?

None of this means that large, exploratory change sets have no value. Sometimes, a big refactor is the best way to learn. I often create a scratch branch where I pull apart a system to understand it better.

But that’s not what I submit for review.

Instead, I use that learning to map out a sequence of clean, logical steps. Then I go back and start fresh, delivering the solution through a set of small, testable MRs. That’s when the real progress begins.

Summary: Strong Developers, Small Chunks

Here are a few things you’ll often see among high-performing developers:

Merge requests are small, focused, and submitted regularly
Blockers are raised early and solved collaboratively
Large refactors are used for learning, but final changes are delivered incrementally

Frequent, small merge requests are more than a habit. They’re the outcome of thoughtful problem-solving and deliberate communication. If you want to move fast and build confidently, this is one of the clearest paths forward.

Why LLMs Won't Replace My Junior Developers

Benoit Doyon — Fri, 07 Mar 2025 14:09:53 +0000

We're hiring quite a bit at Flare these days, so I spend a few minutes each day on LinkedIn to scout candidates. It seems that the algorithm has decided that endless posts describing the downfall of the junior developers in the face of machine learning are going to capture my engagement. I guess it's not wrong in a sense, as it has compelled me to explain exactly why LLMs won't be replacing the junior developers in my team anytime soon.

Learning and Growth Require Real Experience

Junior developers aren't here just to ship code. They're learning how to think critically, solve complex problems and collaborate with the team. My AI assistant might write a function given a decent prompt, but it won't be as useful when debugging production, communicating technical ideas, or adapt to ever-changing project requirements. I can't overstate how happy it makes me when I give an assignment to a junior developer and instead of coming up with a flawed merge request, they come back with a question instead.

Context Matters

LLMs are great at generating snippets of code, but they lack the full context of a project's architecture, business logic, and long-term goals. Junior developers, on the other hand, learn the nuances of the codebase, understand why certain design decisions were made, and can make informed contributions that align with the bigger picture. I don't value junior developers as code monkeys, but rather as wielders of a fresh pair of eyes with which to look at a problem.

Over-Reliance on AI Can Be Risky

Using LLMs as a crutch can lead to complacency. Developers, especially those early in their careers, need to understand why code works, not just what code to write. Developing these habits is what allows them to grow into competent senior developers. If juniors skip the learning process and rely solely on AI-generated solutions, they miss out on developing critical problem-solving skills. It's like using a calculator without ever learning basic math. Sure, you might get an answer, but it all breaks down when confronting changing requirements and a nuanced playground. When building products, this basically means all the time.

Junior Developers Bring Long-Term Value

Investing in junior developers isn't just about the present, it's about the future. Today's juniors are tomorrow's leaders. By nurturing their growth, you're building a team that understands your product deeply, values continuous improvement, and can mentor the next generation. More senior developers also gain a lot by having junior members in the team. Flexing those mentoring muscles and learning how to become a multiplier in a team, instead of being a single contributor, is how developers unlock greater potential.

Final Thoughts

LLMs are powerful tools, and I encourage my team to explore them as a way to enhance productivity. But they're just that—tools. They can't replace the curiosity, growth potential, and human connection that junior developers bring.

If you're interested in fostering an environment where junior developers can thrive, we're currently hiring a lead for our platform team. Send me a message and I'll be happy to chat about building an engineering culture where humans are at the center of everything.

https://flare.bamboohr.com/hiring/jobs/73

Why A Great Developer Onboarding Matters

Benoit Doyon — Tue, 18 Feb 2025 13:32:24 +0000

I think most technical onboarding experiences throughout my career have looked something like:

Receive a company laptop
Clone the code repository
Find the latest person who's been through the painful process of setting up a local environment, and hope that they remember what they're doing, especially when trying to attempt to debug the inevitable errors

A poor onboarding process can lead to confusion and frustration, setting the wrong tone for a developer's experience at your company. On the other hand, a well-structured onboarding process ensures they start with clarity and confidence. At Flare, I believe we've found the key to effective onboarding: structured guidance, hands-on experience, and continuous support. And to be honest, it's nothing complicated. These small investments will go a long way to get developers started on the right foot.

The Cost of Poor Onboarding

Hiring great developers is hard. Once you hire someone who's excited to get started, the last thing you want to do is to be a hurdle to their momentum.

Long ramp-up times – New hires spend weeks or months just figuring out where things are and how to get started.
Frustration and disengagement – Without clear guidance, new developers can feel lost or undervalued.
Higher turnover – If onboarding is disorganized, developers may leave before they ever hit their stride.
Team slowdowns – A poorly onboarded developer pulls others away from their work for constant questions and troubleshooting.

On the flip side, a strong onboarding process accelerates learning, boosts confidence, and makes developers feel like they belong.

What Makes a Great Developer Onboarding Experience?

A great onboarding process goes beyond just documentation and checklists. Here’s what truly makes a difference:

1. Clear Expectations from Day One

Developers should know exactly what’s expected of them, what success looks like, and how they’ll get there. A structured onboarding plan with milestones helps keep everything on track. At Flare, since we work with Shape Up cycles, new developers typically follow a specific learning curve. You spend one cycle onboarding and learning, you spend one cycle executing and contributing within a team, and finally you are ready to lead a cycle and champion a project.

2. Easy Access to Tools and Information

Nothing slows down a new hire like missing credentials or outdated documentation. We make sure to automate setup where possible and ensure essential resources (like API keys, test environments, and architecture diagrams) are easy to find. As part of our onboarding, the new hire updates the onboarding documents to ensure they remain accurate and relevant. This ensures that they are always up-to-date, and free of any ambiguity.

3. Hands-on Learning and Small Wins

Instead of drowning developers in documentation, we let them start with small, meaningful tasks. Fixing a minor bug or improving documentation in their first week builds confidence and helps them understand the codebase faster. The way we do this at Flare is with something we call quests, which are sample tasks that everyone does (ex: change the color of a button in the UI, implement a new API listing feature flags). This way you can get relevant comments from everyone on the team, while also making sure your development setup functions correctly in a controlled environment.

4. Mentorship and Support

Assigning a buddy or mentor gives new hires a go-to person for questions and guidance. This helps them integrate socially and technically into the team more smoothly. On top of the buddy system, we make sure new developers spend a day shadowing each member of the team during their second week. This gives them exposure to different workflows, coding styles, and problem-solving approaches, helping them understand how various parts of the team collaborate and function together.

5. Team and Culture Integration

Onboarding isn’t just about code. We want to help new developers connect with their team, understand the company’s culture, and feel like they belong. Casual introductions, team lunches, and pairing sessions make a big difference. We tend to group new hires in cohorts, and we plan a welcome lunch, as well as introductions during the weekly company all-hands.

The Payoff: Faster, Happier, and More Effective Teams

Investing in great onboarding isn’t just about making new hires feel good, it’s about making your entire team more effective. Developers ramp up faster, contribute sooner, and stay longer. A smooth onboarding experience signals that your company values its people and sets them up for success from day one.

If you want a stronger, more engaged engineering team, start with how you welcome them. Investing in great onboarding leads to faster productivity, higher retention, and a more cohesive team. Take the time to refine your process, and you’ll see the impact in every aspect of your development culture. Onboarding isn’t just the first step, it’s the foundation for everything that follows.

Why (and how) we hire software development interns

Benoit Doyon — Fri, 23 Aug 2024 15:16:47 +0000

Intern recruitment season is upon us! At Flare, we typically hire 2-3 interns each semester, with one joining one of our development teams. As we prepare to welcome a new cohort, we’re also gearing up to recruit for the following semester. Here’s an inside look at what an engineering internship at Flare entails, the benefits we gain as an organization, and how we ensure we recruit top-quality candidates.

What an Internship at Flare Looks Like

Before an intern starts at Flare, we’ve already identified a team that aligns well with their skills and interests. During the interview process, we discuss their previous experience, areas of interest, and what they hope to learn. However, once they’re more familiar with what we do at Flare, they’re free to choose the team they wish to join.

Interns undergo the same onboarding process as our full-time developers. The onboarding starts with an introduction to the company, where they learn about our mission, meet leadership from every department, and get a comprehensive overview of our operations. Following this, they dive into developer-specific onboarding, which includes a series of "quests." These quests are essentially sample tasks that cover various aspects of development, ensuring that interns have correctly set up their environment and tools. Throughout this process, they are guided by a "buddy" and supported by their assigned team. Typically, within the first two weeks, interns are ready to tackle a real issue.

Once onboarded, interns are fully integrated into their development teams, participating in our development cycle (see our ShapeUp article for more details). During their semester at Flare, interns work on two full development cycles. This means they will contribute to two meaningul and time-bound projects. The first project helps them get up to speed, gradually taking on larger tasks as they become more comfortable and independent. By the end of their internship, they’ve gained the experience of delivering two increments of user value—an ideal experience for budding engineers.

In summary, our interns are treated as full team members, working alongside experienced developers on meaningful projects. We set realistic expectations based on their experience level but ensure they are fully immersed in our development process.

Why We Hire Interns

Hiring interns offers numerous benefits beyond just increasing development velocity. While gaining additional hands on deck is valuable, the true benefits lie elsewhere.

Firstly, recruiting interns is an excellent way to engage our team in the recruitment process. It’s a low-stakes entry point that allows team members to gain experience in hiring, particularly those who might be hesitant about recruiting more experienced professionals. Our internship hiring process is shorter and less time-consuming than hiring full-time developers, making it an ideal starting point.

Once interns join the team, it’s a fantastic opportunity for team members to develop mentoring skills. Mentoring is a crucial skill that improves communication, processes, and team interactions far beyond the scope of the internship program. In my view, this is the greatest benefit of having interns.

Moreover, providing a great internship experience is important to us. It not only benefits the interns themselves but also contributes to a positive environment that makes future recruitment easier. It's a great pipeline to cultivate to ensure a steady flow of well-trained junior developers joining the team.

How We Recruit Great Candidates

Our recruitment process for interns consists of two main parts. First, we conduct a one-hour "fit" interview. This interview allows us to discuss the candidate’s experience, explain what an internship at Flare entails, and answer any questions they may have. If there’s a mutual fit, we move on to the next step.

The second step is a technical interview. We believe it’s essential to see interns code to ensure they can be productive within our development teams. Given the steep learning curve and the complexity of our distributed systems, we focus on onboarding interns to our way of doing things rather than teaching the basics of software engineering. Therefore, we prioritize candidates with prior experience and assess their capabilities during this interview.

While coding interviews can be daunting, we strive to make ours as comfortable as possible. We ask candidates to solve a simple problem involving around a dozen lines of code, conducted live over video chat. Though this might seem stressful, we allow candidates to use any programming language, tools, or documentation they’re comfortable with, including Google and language docs. They can also ask questions, and we guide them as needed. Our goal is to simulate real work, where we act more as colleagues than interviewers. Feedback suggests that while candidates may feel nervous initially, they quickly relax and enjoy the exercise.

Conclusion

Thanks for sticking with me through this overview of software development internships at Flare! If you’ve got thoughts on our process, I’d love to hear them. And if you’re looking for an internship yourself, don’t hesitate to reach out—we’re always on the lookout for great talent. https://flare.io/company/careers/

ShapeUp at Flare: A Game-Changer for Project Management

Benoit Doyon — Tue, 23 Jul 2024 17:12:29 +0000

I first encountered ShapeUp during one of my initial interviews for a position at Flare. My soon-to-be manager mentioned, “We’re using a methodology that works well for us, but you might not have heard of it before.” With over 10 years of software development experience under my belt, I was skeptical. “If there was a better way to do things, surely I’d have heard of it,” I thought. Little did I know, ShapeUp would fundamentally change my approach to project management and team dynamics.

Before extolling the virtues of ShapeUp, let me provide some context. Throughout my career, I’ve been part of many dysfunctional teams, as well as some exceptional ones that delivered far beyond the norm. I spent a great deal of time thinking about this and trying to replicate those particular conditions in every team I was part of. I was a solid SCRUM advocate. I tend to think that being “agile” works better with a lowercase “a”, and the guiding principle is to craft a process that best suits your situation. However, despite my dedication to SCRUM, I frequently encountered roadblocks in getting teams to perform well.

Enter ShapeUp

ShapeUp, created by BaseCamp, is a methodology that we use to run projects at Flare. The ShapeUp book is a mandatory read for all new employees, and while it’s concise, I’ll outline the key principles we follow:

Work is scheduled in 8-week cycles
- Each cycle consists of a 6-week project period followed by a 2-week cooldown.
No backlog
- Instead, we have a “shaping” process where top-of-mind tasks are defined into projects.
Blurry project definitions
- The problem statement and goals are clear, but the team is trusted to build the solution within the time constraints. Developers are assigned a problem to solve rather than a ticket to complete.
Cooldown periods
- Developers have the freedom to work on whatever they want during the cooldown.

ShapeUp’s simplicity and elegance lie in the details. Here are the main advantages we’ve experienced:

Meaningful increments
- We always focus on the most important tasks, and 6 weeks is sufficient to build something substantial.
Big-picture focus
- Developers are trusted with significant liberty in solving problems, fostering creativity and innovation.
No “just one more sprint…” death march
- With ShapeUp, projects conclude after 6 weeks, preventing endless extensions and allowing for fresh starts in the next cycle.
Protected developer time
- Developers’ time is safeguarded to focus, free from external interruptions during projects and unnecessary justifications during cooldown.

Cooldowns Are Awesome

Cooldowns are a beloved aspect of ShapeUp at Flare. Business stakeholders often remark, “There’s so much great stuff getting done, we should do cooldowns all the time.”

Cooldowns provide the perfect opportunity to:

Conduct retrospectives and plan the next cycle.
De-risk upcoming projects.
Fix bugs, perform meaningful refactorings, and work on passion projects.
Experiment with new technologies.

Developers get really excited about cooldowns, and the business as well. It turns out that if you hire developers that care about their craft and let them run loose for 2 weeks once in a while, they contribute meaningfully.

Additional Advantages

Interns at Flare, typically with us for a 4-month semester, greatly benefit from the ShapeUp cycles. Aligning our cycles with university semesters and holidays allows interns to:

Onboard at the start of a cycle.
Contribute meaningfully to a project.
Apply their knowledge in a subsequent project, experiencing two full cycles during their internship.

Conclusion

Usually seeing is believing, but something feels right even when just being introduced to the concept of ShapeUp. People immediately perk up when we mention how we work during interviews. Candidates we’ve hired that are experiencing ShapeUp for the first time are now becoming ambassadors. After a year with ShapeUp, I know I’m sold.

ShapeUp is more than just a project management approach. It changes the way we approach problem-solving and team dynamics, fostering trust, creativity, and enabling significant progress. If you’re struggling with your current methodology or just curious about alternatives, I highly recommend giving ShapeUp a try. It might just revolutionize your team’s productivity and satisfaction as it has for us at Flare.