Building what creates business impact, not what’s easiest or generates billable hours
Most technology projects fail because they optimize for the wrong things—developer convenience, billable hours, or process adherence. I take a different approach: understand what creates real business impact, prioritize accordingly, then make it happen.
Value-Based Prioritization
Not story points. Not “easy wins.” Business value.
Every decision gets assessed through three lenses:
Cost Reduction
What manual processes eat time and create errors? Where are infrastructure costs higher than necessary? What repetitive work could be automated?
The critical insight: Automation saving €50k/year creates the same bottom-line impact as €50k in new revenue—often more predictable and with compounding effects year over year.
Examples: Eliminating manual data entry. Optimizing infrastructure spend. Automating reporting that currently takes hours. Streamlining workflows that create errors and rework.
Revenue Impact
What’s blocking growth that technology could address? What would enable your team to sell more or serve customers better? Which capabilities unlock new opportunities?
Examples: E-commerce improvements that increase conversion. Tools that let your team handle more volume. Integrations that open new channels. Customer retention features.
Worker Empowerment
How does this help your team do better work? What frustrating tasks could we eliminate? Does this technology enhance roles or threaten them?
Technology typically gets deployed against workers—surveillance, speedup, job elimination masked as “efficiency.” I refuse that model.
I design automation that eliminates soul-crushing tasks (data entry, manual reconciliation, repetitive administrative overhead) while protecting and enhancing the roles of people doing them. Better tools for meaningful work, not scripts that make humans redundant.
When we automate, we ask: Does this make someone’s job better, or does this eliminate someone’s livelihood? If it’s the latter, we don’t build it.
Examples: Tools that eliminate drudgery so staff can focus on high-value work. Workflows that support rather than pressure workers. Systems designed around how people actually work, not how managers wish they worked.
The Mindset Shift
When something is genuinely high-value through this assessment, the question becomes “how do we make this happen?” not “is this worth the effort?”
Complexity becomes a “how” question, not a “whether” question.
Traditional approach: “This automation is complex—let’s do these simpler tasks first to maintain velocity.”
Value-based approach: “This automation saves €50k/year—same bottom-line impact as €50k in revenue. How do we make it happen?”
This demonstrates strategic business thinking beyond technical execution—understanding P&L impact, cost-benefit analysis, and outcomes rather than just building features or filling sprints.
Real Agility vs. Agile™ Theater
Most “agile” teams spend more time in ceremonies than building software.
Sprint planning that consumes development time. Retrospectives that change nothing. Daily standups that aren’t daily or standing. Velocity tracking weaponized for productivity surveillance. Jira dashboards presented to stakeholders instead of working software.
This is process theater—methodology overhead that consumes budget without delivering business value.
What Process Theater Looks Like
Sprint ceremony overhead: Planning meetings, retrospectives without action, review theater for stakeholder management. Calendar-driven rituals that feel productive but aren’t.
Estimation theater: Story point poker consuming hours to produce unreliable numbers. Time estimates that become commitments creating pressure. Velocity metrics used for surveillance, not improvement.
Rigid process constraints: Sprint boundaries preventing response to new information. “Can’t change the sprint” blocking urgent needs. Artificial release schedules instead of continuous deployment.
Management overhead: Project manager intermediaries between you and the person building. Status meetings about status meetings. Documentation for documentation’s sake.
The dysfunction this creates: Developers padding estimates to avoid pressure. Teams gaming velocity metrics. Work expanded to fill sprint boundaries. Focus on process compliance over results. Budget consumed by methodology overhead instead of actual development.
What Real Agility Looks Like
Deploy when ready, not when calendar says: Features go live when they work, not at sprint boundaries. Customer feedback becomes immediately actionable. Changes happen when needed, not after estimation theater.
Direct collaboration, no intermediaries: Talk to the person building your system. Decisions happen in conversation, not filtered through multiple layers. Questions get answered immediately.
Working software over status updates: See actual progress in production, not burndown charts. Test features as they’re built. Make real decisions based on real usage.
Flexibility that actually works: Change direction when you learn something new. Respond to market opportunities immediately. Adjust priorities based on business reality, not methodology constraints.
Sustainable pace: Consistent quality work at pace maintainable indefinitely. No death marches to arbitrary sprint deadlines. Better results from rested developers than burned-out heroes.
This Isn’t Chaos
Real agility requires more discipline than process theater, not less.
Automated testing catches issues before deployment—not after sprint review.
Infrastructure as code makes changes reproducible and safe—not dependent on manual configuration.
Continuous deployment with proper engineering practices creates more reliability than sprint boundaries ever could.
The result: Faster feedback loops, better business decisions, and more budget spent on development instead of methodology.
Strategic Discovery in Practice
Here’s how value-based thinking changes outcomes.
The request: A client needed a directory website for SEO backlinks.
Standard approach: Build what was requested. Bill the hours.
Value-based analysis: Why do you need SEO backlinks? What’s the actual business goal?
The real opportunity: 12,000 existing customers being underutilized. Customer retention was worth far more than SEO optimization. A partnership ecosystem was waiting to be built.
The shift: From “build what was requested” to “understand the business problem and solve it strategically.”
The result: Partnership platform creating ongoing business value instead of one-time SEO optimization.
This is strategic thinking about business outcomes—not just executing requirements, but understanding what creates value and making it happen.
How We Work Together
Discovery & Assessment
Understand your business model and what creates value for you specifically. Identify cost reduction opportunities, revenue blockers, worker empowerment potential. Assess current technology situation and constraints.
No sales pitch about what I want to build—honest assessment of what moves your business forward.
Strategic Prioritization
Collaborative discussion about what matters most. Evaluate opportunities through the three lenses. Make informed decisions about complexity versus impact.
When something is genuinely high-value, we figure out how to make it happen—regardless of complexity.
Implementation
Continuous deployment means you see progress immediately. Direct collaboration keeps decisions fast and aligned. Strategic thinking throughout—not just executing requirements but understanding business impact of every choice.
Ongoing Adaptation
Learn from real usage and adjust direction. Respond to business changes and new opportunities. Technology that evolves with your business rather than rigid roadmaps that become obsolete.
Technical Commitments
Boring, proven technology: Not resume-driven development. Technology chosen for reliability and long-term maintainability, not because it’s impressive or trendy.
No vendor lock-in: Code written for you to own and maintain. Documentation you can actually use. No secret sauce requiring ongoing dependency.
Knowledge transfer: Goal is your autonomy, not your dependency. If you want to bring development in-house later, the systems support that.
Accessibility as standard: Universal design approach, not afterthought additions. Building systems that work for everyone from the start.
Worker protection during automation: Consider worker transition, training, and empowerment—not just efficiency gains. Focus on enhancing roles rather than eliminating them.
Different From Typical Approaches
| Corporate Consultancies | This Partnership |
|---|---|
| Optimize for billable hours | Optimize for business outcomes |
| More meetings, more complexity | Direct collaboration, less overhead |
| Scope expansion | Value-based prioritization |
| Vendor lock-in | Knowledge transfer and independence |
| “Agile” Agencies | This Partnership |
|---|---|
| Story points and velocity | Business value assessment |
| Sprint ceremonies | Continuous deployment |
| Process adherence | Results focus |
| Project manager layers | Direct collaboration |
| “Best Practice” Teams | This Partnership |
|---|---|
| “Easy wins” for velocity | High-value work regardless of complexity |
| Developer convenience | Business outcomes |
| Estimation theater | Honest complexity conversation |
| Rigid sprint boundaries | Real flexibility |
Who This Works Best For
Businesses where genuinely high-value work needs to happen regardless of complexity. Where cost reduction directly impacts survival. Where manual processes are eating significant time and money.
Organizations tired of process theater who want working software over status meetings, results over methodology compliance.
Teams wanting strategic thinking about what actually moves business forward—not just technical execution of requirements.
Mission-driven organizations where technology should serve the mission, not consume budget in overhead.
