00Independent consulting and delivery
Your strategyisn't shippingitself.
A three-year plan* with nothing shipped is a document, not evidence. So we start with the problem and build the first working piece. That shows what breaks, what is still unresolved, and where you need real customer feedback before committing further.
* Three years! More like two quarters now!
Station · Agate Pass · 47.71° N / 122.55° WA narrow tidal strait between Bainbridge Island and the Kitsap Peninsula. Fast current, shallow margins, a passage you read before you transit.
Approach
Every engagement ends with something running.
Most consulting engagements end with a recommendation and a page count. Ours end with viable code in your repository, running against your data, on a trajectory towards integration and production.
We start with the problem, not with a product. No cloud vendor pays us and no licence revenue reaches us, so the answer is not decided before we arrive. What to build, what to buy, and what to leave alone comes after we know what is actually wrong.
This work exists because your teams are already committed. The roadmap item three quarters out never gets its first honest attempt. That is the part we take, so nobody comes off what they owe you this quarter. We work across your leadership, engineering, and customer-facing teams to agree what matters most. Then we show it working: a model, a small build, something real enough to judge before it is funded.
Fig. 1Innovation, feedback, feasibility
Figure scrolls sideways
We can come in at the beginning, or at a mid-point to prove out something already under way.
Schematic. Illustrates the route, not a fixed sequence or duration.
Fig. 1aWhere the work fits
Figure scrolls sideways
Your team is committed across every quarter on the board. The item three quarters out never gets its first honest attempt. That window is the one we take.
Schematic. Illustrates a typical engagement window; not measured data.
Your business problems are never only technical.
Decades of delivery teach you that the thing blocking a programme is rarely the thing named in the status report. We work through all of it, in the order that matters.
Technology
What is actually running, what still depends on it, and what it costs to keep alive.
Culture
What gets rewarded, what gets quietly ignored, and what nobody will say in the meeting.
Habits
The workaround that became permanent, invisible now to everyone who built it.
Process
Steps that survive because of a problem somebody solved years ago and nobody has revisited.
Strategy
Whether the plan on paper still matches what the business actually needs this year.
Market
What customers will pay for, and what competitors have already made table stakes.
Delivery context
What your teams are already committed to, and what that realistically leaves for anything new.
We unwind these until something moves on the top line or the bottom line. That is the only reason to touch any of them.
Soundings
Six questions worth a conversation.
Written for engineering and product leadership. The same few things stall this work: unclear ownership, unmapped dependencies, and a business case written before anyone looked.
- 01
You have an AI or modernization strategy. How much of it has actually shipped?
Strategy is cheap to write and expensive to postpone. We pick one piece, build it, and report what the plan got wrong before the budget is committed. A few lessons now are worth millions later.
- 02
Are you still paying, year after year, for inventory nobody uses?
Duplicative systems quietly hold opex flat. We map what is actually running and retire what can go safely, for a fraction of what keeping them costs. Cost comes down when something is switched off, not when it is listed in a report.
- 03
You built something other companies would pay for. Is platformizing it worth the cost?
Sometimes the answer is no, sometimes yes. We price the real work of making internal software market ready, and shape the options from both the business and the engineering angle.
- 04
Your teams are fully committed. Who is preparing the thing that is six months out?
We do. Your engineers stay on what they already owe you this quarter. The new work still starts, and your team owns it at handoff.
- 05
Is a deliverable off track, carrying unresolved issues, and not ready for production or scale?
We start with what is actually blocking it rather than what the status report says, clear the path to production, and hand it back on track.
- 06
Are you about to hire an AI strategist or architect without being sure what the role should deliver?
The role gets easier to define once the business problem does. We find the problems worth solving first, which makes the scope, the schedule, and the budget obvious, and tells you whether the job needs to be full time yet.
Deliverables
- 01
First working piece
We cut the cost of finding out. A rough idea becomes something running in hours or days, not quarters, tested against your data and your users. Agentic workflows included.
We build the smallest honest version, put it in front of real users or real data, and report what broke. Before that, we check the data can actually carry the decision, so a model or an agent is not built on ground that will not hold. You decide with evidence instead of a forecast.
- 02
Accelerator adoption
Someone already published most of your system. We adopt it, move it onto the cloud and the models you actually run, and finish the fifth that is specific to you.
We have years of experience adopting reference architectures, and they have become one of the fastest routes into production for AI work. A well-made one carries around four-fifths of the build. The fifth it cannot carry is the part that could not be published because it is yours: your identity provider, your data, your retention rules, your cost ceiling, and your definition of a correct answer. That fifth is where this work stalls, and it is the part we take.
Patterns with a published starting point
- Content processing
- Document knowledge mining
- Conversation and call-centre mining
- Multi-agent workflow automation
- Code and data-estate modernization
- Chat with your own data
- Customer-facing chatbots
- Container and cloud migration
- Real-time operations intelligence
Adoption is not confined to the cloud that published the pattern. The target can be the cloud, data platform, and models you already run and already govern, and working out which of those is a two-week move and which is a rebuild is the first thing we do.
- 03
Platformization assessment
Internal software other companies would pay for. We price what taking it to market actually costs, so the decision rests on a number.
Selling it to other companies means multi-tenancy, support, security review, pricing, and a route to market. We price that work and can accelerate both the evaluation and the build.
- 04
Make or buy
Build it, buy it, or leave it alone. The decision usually turns on integration, not on features.
We price the whole picture: integration effort, security exposure, resilience, and who maintains it in year three. Feature comparisons hide most of that cost, so you get the number the vendor sheet leaves out.
- 05
Data put to work
Modeling, forecasting, and optimization that end in a decision, not another dashboard nobody opens on Monday.
Martin has spent three decades turning complex data into practical information. We build the model, wire it into the workflow, and leave your team something they can run without us.
- 06
Duplicative inventory reduction
Systems you replaced but never switched off. We take them off the bill, in sequence, without breaking what still depends on them.
We find what is running, what still depends on it, and what can go. Then we retire it in sequence, with the rollback written down before anything is touched. You get a smaller bill, a shorter dependency map, and nothing switched off that someone still needed.
- 07
Impact measurement
A working measurement system, wired in before the spend, so the next funding decision has evidence behind it.
We agree the success metric with you, instrument the program, capture the baseline, and hand over a live readout built with statistical discipline. You get a defensible read on impact instead of a slide of selected wins.
- 08
Back on track
A build that stalled short of production, carrying unresolved issues nobody has had time to work through.
We assess what is genuinely blocking it, sequence the fixes that have to land first, and get it to a state your team can carry into production and scale.
Fig. 2What a feature comparison misses
Figure scrolls sideways
Features are where the argument happens. Integration, security, resilience and year-three maintenance are where the money goes, and a vendor comparison shows none of them.
Schematic. Below the cut, a longer bar means greater cost. Relative lengths illustrate where cost typically hides; not measured data.
Operating principles
- 01
Go simple. It'll complicate itself soon enough.
Start with the plainest thing that could work. Once it is running, most of the real solution reveals itself on its own.
- 02
We'd rather bet on your people than on a tool.
Tools get replaced every four years. The engineer who understands your system does not. We hand over what we build, so the knowledge stays after we go.
- 03
Strategy is a dream until you execute.
A plan shows you what you hope is true. Executing a piece of it shows you what is true. Only one of those changes a decision.
- 04
Be prepared. Always scout.
Know the terrain before you commit the budget. Dependencies, owners, data quality, and the thing nobody wants to mention in the kickoff meeting.
- 05
Risk is good. Manage the mitigation.
Avoiding risk is how organizations stop moving. Name the risk, size it, plan the way back, then take it deliberately rather than by accident.
- 06
Demonstrate it.
Design and ideas hold little value until someone can use them. Show the working thing. Every argument gets shorter once it is on screen.
On AI
AI is an enabler. It doesn't replace people.
Martin was part of early cloud development, and is part of early AI adoption now. The same argument ran then, and it resolved the same way.
Cloud did not replace engineers. It changed what a small team could attempt in a quarter. AI is doing that again, faster, and with more noise around it.
AI is one component. There is still data, product development, and the unglamorous integration work that decides whether anything reaches production. No tool carries a project your people do not understand.
So the useful question is never which model. It is which decision gets faster, which cost comes down, and whether you can explain the output when someone asks how it got there.
- 01
Impact
AI should make your best people more effective at the work only they can do. If it is not doing that, it is a subscription.
- 02
Responsible use
Know what the system was trained on, what it is allowed to touch, and who reviews the output before it reaches a customer.
- 03
Security and vulnerability
New capability is new exposure. Data handling, model access, and prompt paths belong in the threat model from the first sprint, not the last one.
Where agentic work usually lands
- Customer support triage and resolution
- Lead qualification and routing
- Internal workflow automation
- Reporting and analysis
- Document processing and extraction
- Employee onboarding
These are the usual candidates. Whether any of them is worth automating in your business is the first thing we test, not the last.
Domains
- Product development01
- Modeling, forecasting, and optimization02
- Agentic workflows03
- Supply chain, transactions, and inventory04
- Make or buy decisions05
- Integration, security, and resilience06
- Cloud and platform modernization07
- Program evaluation and impact evidence08
We do not run managed services or take on long-run application support. If that is what you need, we will say so on the first call.
How we price, and why.
The way we charge follows from the way this practice is built. Both are deliberate.
You are not funding overhead
There is no bench to keep busy, no sales organisation, and no floor of offices to carry. You pay for the work and the judgment behind it.
Nobody else is paying us
No vendor margin, no referral fee, no resale commission. What we recommend is what we would do if the budget were ours.
Scoped to the question
We size the work to what needs answering, not to what is available. If a smaller piece settles it, we will say so and do that instead.
Light on administration
Delivery is hard enough. We do not add change-order cycles, weekly status theatre, or a discovery phase you pay for before anything is built.
Measured on impact
Engagements end with something running and a number you can defend in a review. That is the deliverable. Hours are only how we got there.
08Nonprofit and underserved
Tech for good
If you are a nonprofit, or you serve people who are underserved or disadvantaged, get in touch! We are convinced we can help, and we will find a way to make the engagement work.
Tell us what you're working onBuilt for companies of any size.
Global enterprises, start-ups, and public sector. What matters is the problem, not the headcount.
Thirty years has meant working at both ends. Global enterprises carrying years of accumulated duplication across dozens of engineering teams. Start-ups where a single decision sets the trajectory. Public sector programmes where the reporting obligations are the hard part, not the code.
What travels across all of them is the same. Find what is actually wrong, build the piece that proves it, hand it back. Size changes the constraints. It does not change the method.
Partners
Martin HaaseFounding Partner
Over thirty years of building the thing rather than describing it.
Martin recently retired as a Senior Director at Microsoft. Much of that time was spent with hundreds of customers working through modernization, which is a polite word for deciding what to keep.
Martin has worked through this with dozens of large companies that mis-estimated the work or put it off. The savings they forecast, tens of millions, never arrived. The effort ran over. The schedule slipped six months to a year. In nearly every case it was visible and avoidable before the budget was committed.
Before that: economics and public policy, then healthcare analytics, then building and selling software. The through line is platforms, modeling, and turning complex data into information people can act on.
He was part of early cloud development. Now he is part of early AI adoption. Both times the lesson was the same: the hard part is rarely the technology. It is deciding what to stop doing, what to start doing, and then actually doing it. That is the work we take on, and we stay with it until your team can carry it.
On the recordWe love data.
David NguyenPartner
Fifteen years building enterprise applications end to end.
David has spent fifteen years building enterprise applications from the database through the API to the interface. Most recently in the public sector, before that at Smartsheet, and seven years at Microsoft on Xbox.com and Xbox Live.
He works the whole stack rather than a slice of it. That is what makes a small practice viable: one person who can define the schema, write the service, build the screen, and own the pipeline that ships it.
Much of that work has been in government and commercial environments, where software has to be secure, auditable, and still running years after it was handed over.
On the recordWe ship it.
Contact
Start with one conversation.
Email Martin