August 31, 2026
Sixty to ninety days after cutover, most build champions do the same thing: they check whether anyone's complaining, hear nothing, and quietly file the project under 'worked.' That's not a retrospective, that's an absence of data. A build can underperform for months without generating a single complaint, because people don't complain about a tool -- they just route around it. They keep a spreadsheet on the side, they email the old way, they ping someone instead of using the new form. None of that shows up as a support ticket. It shows up, eventually, as a leadership conversation about why the last three builds didn't really deliver what they promised, and why the team should just go back to buying software. That conversation is avoidable, and the way you avoid it is by actually measuring the thing at 60-90 days instead of assuming it.
You didn't build this on a vibe. If you followed the one-page pitch for building instead of buying, you wrote down specific success criteria before anyone touched a build tool: maybe 'reduce ticket resolution time by 20%,' or 'eliminate the manual export step entirely,' or 'support 40 concurrent users without lag.' If you ran a cutover through shadow mode, you have an even sharper set of pass/fail criteria from that trial period. Go get that document. Don't rewrite it from memory -- pull the actual file. Then go line by line and mark each criterion met, partially met, or missed, with the number next to it. 'It feels fine' is not an entry in this table. If a criterion was 'cut resolution time by 20%' and you don't know the actual number, that's your first finding: you don't have the instrumentation to answer the question you asked, and that's worth fixing before you move to step two.
Intent and behavior diverge fast once the novelty wears off. Pull login and usage data from the tool itself -- most ViibeStack apps have this natively -- and compare it against how many people were supposed to be using it daily. If the workflow was supposed to fully replace a SaaS subscription and only 70% of the relevant work is actually happening inside the new tool, that's not a rounding error, that's a partial replacement, and it changes your cost math in step three. Look specifically for drift: is anyone still exporting to a spreadsheet for reporting because the built-in reports don't cover a case they need? Is anyone emailing approvals because the in-app approval step is one click too many? These gaps are usually small and specific, which is exactly why they're easy to miss from the outside and easy to fix once named. Write down the actual adoption percentage. Don't round it up.
The build time is sunk. Nobody's getting that back, and it's not the number that matters now. What matters is the ongoing cost: the subscription you canceled, against the actual hours spent since launch on bug fixes, tweaks, one-off support requests, and 'can you just add a field for me' asks. Add those hours up, put a dollar figure on them, and compare that monthly number to the SaaS bill you used to pay. Most purpose-built internal tools genuinely do cost less to run than what they replaced -- that's the whole premise behind replacing a subscription-heavy stack with something scoped to your actual workflow -- but 'most' isn't 'always,' and this is the step where you find out which category you're in with real numbers instead of a hunch. If your ongoing support cost is creeping up toward what the subscription cost, that's a signal worth taking seriously, not explaining away.
'How's the new tool going?' gets you a shrug and a 'yeah, it's fine.' That's not useful. Ask the people who use it every day something specific: 'What's the one thing you still do outside this tool that you wish you didn't have to?' That question surfaces the exact gap -- the manual reconciliation step, the missing filter, the report they still build by hand -- that a build champion, who mostly sees the tool from the outside, will never notice on their own. Ask it individually, not in a group meeting, because the honest answer in a group is usually 'nothing comes to mind' and the honest answer one-on-one is a specific, fixable complaint. If three people give you the same answer, you've just found your next small build task, and it's probably a lot cheaper to fix than the workflow was to build in the first place.
Sometimes this retrospective comes back clean: criteria met, adoption high, costs down, feedback minor. Great -- write it up, because that write-up is what makes your next build-vs-buy pitch land faster. But sometimes it comes back with real problems: adoption stuck at 70% because of a gap nobody addressed, support hours creeping toward the old subscription cost, or a workflow that turned out messier to maintain than expected. If that's what you find, don't round it up to 'basically fine.' Name the specific gap and either fix it -- often it's one workflow, not the whole app -- or make the case to go back to a bought tool for that particular piece. A disappointing result on one build is not a verdict on building in general; it's information. Pretending a miss was a win is what actually erodes trust in the next build, because eventually someone else does the math and finds the gap you didn't mention. It also helps to keep the maintenance side honest ongoing -- the bus-factor checklist is worth revisiting here too, since a tool nobody can maintain will eventually show up as a cost problem in this same retrospective.
Building the app was never the finish line -- it was a bet, and this retrospective is how you find out whether the bet paid off. Skip it and you've got a project that felt fine, which tells the next person weighing build versus buy nothing useful. Do it, with real numbers on adoption and cost and a specific answer from the people using it daily, and you've got evidence. That evidence is what turns 'we built something' into 'we know whether building was the right call' -- and it's cumulative. Every honest retrospective, including the ones that admit a miss, makes the next one-page pitch sharper and the next build-vs-buy decision better informed than this one was.