The article, by Deep Nishar and Nitin Nohria, argues that generative AI is dissolving the economic logic that made standardised enterprise software the only practical choice for most organisations. For thirty years, companies have largely bent themselves around their software. Custom solutions were prohibitively expensive, so we so we normalised adapting our processes to fit the most appropriate tool. That bargain is breaking. AI has made custom software accessible again.
The central question the piece asks is one we've been answering for ourselves: which workflows do we actually need to own?
We started taking our own advice.
We spend a lot of time helping other organisations think carefully about their software decisions. Whether to modernise a legacy platform. Whether an off-the-shelf tool is genuinely fit for purpose or just familiar. Whether a build decision is justified by the distinctiveness of the problem, or whether it's rationalisation dressed up as strategy.
At some point late last year, we turned that question on ourselves.
It's a familiar enough story. We were running a consultancy on a stack of general-purpose SaaS tools that didn't talk to each other particularly well and were never designed for the nuance of our context. Our CRM didn't understand that we work substantially in government procurement cycles, where a contact goes quiet for six months not because they've lost interest but because a live process is underway. It had no concept of an ICP built around NZ-specific sectors. No "Crown Entities." No "Māori & Iwi." No "Aquaculture." Our contract management was a mix of shared drives, spreadsheets and institutional memory. Signals from client conversations lived in email threads and meeting notes that didn't always land in front of the right people at the right time.
None of this was catastrophic. It was just friction, accumulated over years, accepted because the alternative seemed expensive and complicated.
Then, suddenly, it wasn't.
MadeCuriOS.
At the end of March 2026, we launched the first version of MadeCuriOS. A custom operating system for MadeCurious, built on modern, AI-native infrastructure with AI helping the intelligence work.
Within weeks, it had a full contracts module where dropping a signed PDF on a folder triggers AI extraction of the counterparty, value, dates, key terms, signatories and risk flags. Variations live as events on the parent contract, with each amendment showing the underlying relationships. Renewal tracking captures not just the expiry date but who has to give notice and when.
It has a Signals module that reads Gmail and meeting transcripts and surfaces commitments, risks, opportunities and questions. Not as a dump of raw text but as structured, triaged items that can be shared between teammates, with a quality feedback loop so extraction accuracy improves over time. When a conversation with a partner produces something someone needs to act on, it gets to the right person rather than staying in an inbox.
We have a Discovery Board, a full product backlog feature for capturing ideas, running them through an evaluation funnel and tracking them from hypothesis to shipped. When ideas and solutions are flowing fast, visibility is golden. There's a Slack integration that does ambient listening in connected channels and proposes capturing idea-worthy messages, but lets the individual confirm their intentions before anything gets created.
It has a daily briefing that posts to Slack every morning: overdue items, meetings today, recent signals, people who need a nudge. It takes about thirty seconds to read and replaces the fifteen-minute mental load of reconstructing your day from scattered sources.
Best of all, we've held the pen on a sector taxonomy that includes the organisations we actually work with. Not a generic industry dropdown ported from a US SaaS product, but a list that reflects how New Zealand's economy is actually structured, what our role-titles actually look like.
The most important question.
The HBR piece frames four models for how organisations will relate to software going forward: build, compose, collaborate or buy outcomes. What our experience has taught us is that the choice between them matters less than the question it depends on.
Does this workflow encode something genuinely distinctive about how we operate? That's the question worth asking before any of the four.
Our sector taxonomy exists because our CRM needs to understand our market the way we understand it. Not an afterthought or a custom field bolted onto someone else's data model, but a first-class part of how companies are classified and how our ICP logic works.
The daily briefing exists because the job it does, holding the shape of the day before you start it by bringing together and prioritising signals from across our collaboration and communication tools, is one the off-the-shelf morning digest tools can't do. They don't know what a nudge is, or what a signal is, or what a live procurement process means for how we interpret contact silence.
These are workflows worth owning because they encode how MadeCurious specifically operates. Our accounting is not, project time-tracking is not. We buy outcomes for those, and we don't feel the loss.
Clarity before code.
There's a version of the custom software argument that treats the reduced cost of building as permission to start immediately. We think that gets it backwards.
The act of specifying something clearly enough to build around it forces a precision about the workflow you can't get any other way. When one of our team built a tool for managing our annual review process, that process of articulation revealed that parts of the workflow itself needed to change. The software building process didn't just encode the workflow. It forced us to inspect and improve it.
That's really only possible if you do the thinking & consult your colleagues before you jump to code.
When we're building for ourselves and treading closer to systems that hold sensitive information, the same discipline applies as when we're building for partners. Permission structures have to be right before a single line of code is written. In those areas, requirements shaped the entire codebase: database-level security policies, a full audit trail, a 46-test suite validating access controls. Security enforced at the database level, not just the UI. Speed never comes at the cost of rigour when rigour is scoped into the brief from the start.
The technology choices matter in the same spirit. We use modern, AI-native tooling, infrastructure where the AI has deep context, where the major architectural decisions are largely resolved, and where almost all the cognitive effort goes into the actual business logic. We also deliberately chose tools our team already works with in our delivery practice. That means the code is reviewable, the patterns are familiar, and the tools are maintainable by someone other than the person who built them. The goal, as one of our engineers put it, is building resilience in systems rather than individuals.
The part less people write about.
The HBR piece describes this shift in fairly triumphant terms. The economics have changed. Custom is now accessible. The age of bespoke has begun.
We think that's kind of true. It also understates the difficulty of the actual work. We're genuinely worried by the quality of some of what we're seeing getting built. We've spotted significant security and privacy risks in products people are trying to bring to market. Information management and permission structures feel like they're going to matter far more in the coming years than they've perhaps mattered in the past.
Even with all our experience, the budget formatter in MadeCuriOS was off by 100x at launch. Gmail threads that had already synced once weren't updating when new messages arrived, so an evolving conversation with a client produced no fresh signals after the first sync. The cron jobs that send the daily briefing were blocked by auth middleware and silently failing. None of these are catastrophic problems, we spotted and addressed them rapidly. But they're real, and they need someone paying careful attention to the system's behaviour over time, not just at the moment of build. All three of these issues were actually found by us starting to use the system rather than by our pre-release testing, and all three were fixed, fast. We think that is now the actual shape of the work, and perhaps many organisations aren't ready for the ongoing effort of getting custom-builds right.
The HBR article notes that organisations which rush to automate without re-architecting their data and processes find that quality suffers, edge cases accumulate and systems become difficult to manage. That's accurate. What it doesn't fully capture is that even when you do the work carefully, even when you've thought hard about which workflows to own and why, the system will still surprise you.
The discipline of understanding what you've actually built, and maintaining that understanding as it grows, isn't a one-time investment. It's ongoing. That's not an argument against building. It's an argument for being honest about what building requires, and deliberate in who you partner with to build anything worthwhile.
Six months of changing our minds.
The first four weeks are the part that sounds impressive. They are also(possibly) the least interesting thing about our story.
What we have now is a change log running from the end of March to this week, and reading it back, the pattern isn't actually one of velocity. It is a system being corrected and enhanced by the business it serves, repeatedly, in ways nobody could have specified in March.
Meetings are the clearest example. We built initial functionality the obvious way. You see the meetings you were invited to. That is the instinct every calendar gives you and it wasn't quite right. Six months of use made it obvious why. A contact's page ended up showing a partial history, with the gaps falling exactly where a colleague's relationship with that person sat. Instead of a holistic view of all of our touchpoints into a relationship - the record looked more complete than it really was. In September we inverted the default. Now, every meeting is visible to the whole team, while the transcript is held back, because a transcript is a word for word record rather than a summary and we think that belongs to the people who were in the room.
That decision was not available to us in March. It took six months of looking at parts of a relationship history and wishing we were better joined-up.
The same month, we built the opposite rule too. Anything where the fact of the meeting is itself sensitive, can now be marked confidential. The whole record disappears for everyone who wasn't there, not just the notes, because even the title of a meeting can give the game away. No transcript is fetched, none can be pasted or uploaded, and none is sent to Claude. Ask a confidential meeting a question and it refuses. The rule sits in the database rather than in the sync, so the next instance of a recurring board meeting arrives confidential without anyone having to remember. This is great for operational hygiene, but we also do a lot of work under NDAs and wanted to ensure we codified our disciplines where that really matters.
Most of the conversation about AI in business systems is about what the system can now do. Some of the most valuable work we have done on ours has been deciding what it must never do.
Then there is the work that exists because the business has changed. Tender sourcing became an action item this quarter, so tender notices now land in a triage queue, each with a one line reason for why it is there. A second source from Australia followed the next day, arriving by email alert rather than a public feed. None of that was in anyone's head in March but as you work deeper into the workflows more and more innovation and new ideas become possible.
The argument for owning a workflow is usually made about the build. We think it is really about the second change, and the tenth, and the one you make on a Tuesday because a conversation last week showed you something. That rate of change is the return.
What this means if you're not a software consultancy.
We're building MadeCuriOS ourselves, which makes us an unusual test case. Most organisations don't have a team who've spent 25 years building software and solving organisational challenges with technology on hand.
But that's also the point the HBR article is making. The economics that made this kind of project feasible only for software companies are dissolving. What took months of engineering effort can increasingly be produced in days. The barrier isn't technical capacity in the way it used to be.
What the barrier still is, and what we think gets underestimated in a lot of the conversation about AI-enabled bespoke software, is the clarity required before you build and the ongoing investment it takes to solve something that stays right in a dynamic and changing environment.
We had that clarity because we'd been frustrated by the gaps for long enough to understand them precisely. We knew exactly where the friction was and why the generic tools weren't filling it. That knowledge didn't come from a workshop. It came from years of noticing.
The organisations that will do this well aren't necessarily the ones that move fastest. They're the ones that understand their own workflows well enough to know which ones are worth owning.
That's a harder question than it sounds. But it's the right one to start with.
* This article was prompted by "The End of One-Size-Fits-All Enterprise Software," published in Harvard Business Review on April 23, 2026, by Deep Nishar and Nitin Nohria.
FAQ
How do you decide which workflows are worth building custom software around?
Ask whether the workflow encodes something genuinely distinctive about how your organisation operates: your decision logic, your regulatory context, your specific market. If a competitor could buy the same standard solution and it would serve them equally well, you probably don't need to own it. If the workflow reflects something particular about how you create value, it's likely worth building around.
Isn't building custom software risky for organisations that aren't software companies?
Yes, but the nature of the risk has changed. The bigger risk used to be the build itself: the cost, the time, the technical complexity. That barrier is lower than it was. The risk that remains is building the wrong thing because you weren't clear enough about the problem first. That's a clarity risk, not a technical one, and it applies regardless of how you build.
What's the difference between building something bespoke and just adding customisation to an existing platform?
Customisation adapts a standard tool to your needs within the limits the vendor has defined. Building bespoke means the workflow is designed around how you actually operate, not around someone else's data model. The difference shows up at the edges: in the things the standard tool can't represent, the fields that don't exist, the logic that has to live in a spreadsheet because the platform doesn't support it.
Does using AI to build mean you can skip the upfront thinking?
The opposite. The teams we've seen get the most out of AI-assisted development are the ones who do more thinking upfront, not less. Get the architecture right. Get the data model right. Get the permission structure right. Get the brief to the point where the plan is solid, then hand it over. The AI accelerates execution dramatically. It doesn't substitute for knowing what you're building and why.
How long did it take to build MadeCuriOS?
The first version went live at the end of March 2026. The contracts module, full task management, Discovery Boards, Slack integration and the daily briefing were all live four weeks later. That pace would not have been possible without AI-assisted development throughout. The more useful number perhaps is the six months since, which have produced a continuous record of change, including reversing decisions we made at launch. The build was fast. The system likely doesn't have a finish-line.
What happens to bespoke software after it's built?
This is the question worth asking before the build, not after. Bespoke software nobody maintains decays faster than the standard tool it replaced. Ours has changed most weeks since launch, and the changes that mattered most were the ones we could not have specified upfront: a default we had set the wrong way round, a permission rule the business turned out to need, a new source of work. Plan for the changing, not just the building.
