When the Business Starts Sketching SoftwareAI lets business teams describe the software they want long before they understand the technology. What happens next is the interesting part.

Steven Gerson · May 2026

1. The Starting Context

I have been working with a luxury hotel resort on contract, supporting a number of projects. The most defined among them was integrating two new systems, ireckonu and Profit Room, with each other and with the existing property management system. Beyond those, the brief was broader: find pain points across the business and see what could be done. That has taken me into marketing, reservations, finance, spa, golf, operations, HR, maintenance, and design.

I am a systems thinker, comfortable in software and solutions architecture. What has changed for me recently is what AI has done to the cost of building. I have fast, capable development teams on hand at any moment, through paid-for intelligence. The cost of producing software has collapsed. I can ship thousands of lines of high-quality code without hiring an engineer.

When building costs collapse, the risk shifts to building the wrong thing. The work of deciding what should actually exist matters more than ever.

So I have been moving through the business, finding pain points and shipping things to solve them. Some projects are ordinary. Some are stranger. Financial reconciliation has been one of the bigger ones.

Along the way, almost as a by-product, I have been building a data platform underneath. Where a system has no API of its own, I pull the data in with browser automation, build internal APIs on top, and let products sit on top of those. Caching, telemetry, and MCPs followed naturally. New ideas land quickly because most of the plumbing already exists.

The second wave has been the more interesting story. As the tools started landing, the business itself became inspired by what was possible. People began bringing back richer requests. The shape of the demand coming back has changed. That is what this piece is about.

People sketch what they want with AI, then bring it to me.

The upstream side of software creation has changed. People can describe what they want more clearly, show a rough shape of the solution, and arrive with something that looks more like a draft than a blank sheet of paper.

2. Better Briefers

What AI has done is make business users much better briefers. The shift is upstream, where people describe and shape problems before any engineering work begins.

They can talk to AI about a process that annoys them. They can explore what an ideal workflow might look like. They can produce a mockup, a static view, or a rough prototype. They can build a spreadsheet that captures the logic they think they need. They can bring a semi-formed artefact to someone technical and say, in effect, this is what I wish existed.

That changes the work on the other side. Historically, it often started with extracting a real requirement from a vague complaint. Now the input is denser. The person arriving brings a shape, often a precise one, sometimes pointing at a different problem than the one they articulated. Either way, there is more to work with.

The work on the other side becomes about validating which requests are worth building, reshaping the ones that need it, and turning the survivors into something the rest of the system can absorb.

3. Demonstration Changes What People Think Is Possible

The loop starts because someone demonstrates what can be done. That matters more than it sounds. Once a team sees a workflow improve quickly, the organisation starts treating its bad processes as something it can change.

Demonstration changes what people think the work is allowed to look like. Before, they accept awkward handoffs, manual trackers, and spreadsheets as if those were fixed. After, they start asking whether those things actually need to exist.

The demonstrations themselves are often small. A rough internal tool. A replacement for a manual spreadsheet. A workflow that gets a genuinely annoying task out of the way. What matters is that the business sees a process bend.

Once that happens, people’s own expertise starts to feel like valid product input. Their pain points feel solvable. Their imagination expands because it has been given evidence.

4. The Emerging Loop

The pattern that follows is straightforward, and powerful.

Each stage matters. Demonstration makes possibility visible. Inspiration makes people curious. Imagination turns that curiosity into rough solutions. Those solutions arrive as a prototype, a spreadsheet, a mockup, or a conversation. Translation turns them into something real and safe. Then the new thing gets used, and the cycle starts again.

This is a feedback loop. Every successful delivery creates more belief. Belief creates more ideas. Ideas create more demand. With the new capacity comes a new appetite.

5. The Platform Landing Zone

The imagination layer only works if there is somewhere for it to land. Internal APIs, a stable data model, controlled access to suppliers, known hosting patterns: that is the landing zone. With it in place, ideas can become operational software in days rather than months.

A less obvious effect runs in the other direction. What the platform can already do shapes what people are able to imagine. The reservations team have a unified availability view across rooms, dining, spa, golf, and the rest of the estate. Once that exists, the next ideas reach further: could that same data draft replies to enquiry emails? could it surface upgrade opportunities at check-in? could it route an enquiry directly into a bookable offer? Each of those presupposes the dashboard. Without it, none of them appears. Platform investment shapes what the rest of the business can dream up.

There is a safety dimension too. Raw supplier APIs and sensitive systems should sit behind something. They carry real cost, rate limits, and commercial risk. A well-meaning workflow can mutate data in surprising ways. Internal APIs sit in the middle: they wrap the risk and expose only the parts that are safe and useful.

The principle is simple: expose the capability. Wrap the machinery.

6. Where AI Earns Its Keep

AI is good at programming. That side of what AI does gets less attention than chat and drafting, but it is the more useful one for someone trying to build operational software. The cost of writing software, especially internal software, has collapsed. I can produce thousands of lines of high-quality code in a day, with tests and structure, without hiring an engineer.

The bottleneck used to be implementation. The bottleneck now is judgement.

Not everything should be an AI product

The temptation is to make everything an AI product. That is usually a mistake. Most operational problems are better solved by deterministic software: faster, cheaper, more predictable, easier to test, easier to trust.

AI earns its keep on problems that need natural language, classification, summarisation, or judgement under ambiguity. Rules handle the rest.

One AI gateway

The architecture reflects that. There is a single AI gateway. Every product calls it when it needs AI, with usage, latency, and prompts tracked in one place. Around it sit plain Node and Python services with caching, business logic, and clear contracts.

That separation matters because AI is expensive to run, harder to debug, and less predictable than deterministic code. Centralising it lets the rest of the system stay calm.

The reservations inbox

The reservations inbox shows the mix in practice. The team handling guest emails was overwhelmed: stay enquiries, package questions, dining and spa requests, sometimes mixed together in one message.

Building from scratch would have taken months. Building on top of what already existed took days.

AI classifies the email and drafts the response. Rules extract the structured fields. A deterministic availability service answers the stay viability question across rooms, dining, spa, golf, and Kingdom. A static knowledge service supplies the rate and policy text. Each step uses the tool that is right for it.

Where the answer is yes and the customer is ready to book, the pipeline will soon generate a one-click ProfitRoom offer in the email itself.

Two MCPs, two jobs

The platform exposes two MCPs to AI agents. One is broad and operational, giving an agent access to the full estate (golf, reviews, reconciliation, knowledge) for investigations and reports. The other is narrow: a small toolset for answering customer enquiries, scoped to room availability, sell messages, restaurant, spa, golf, and Kingdom checks.

The split is deliberate. A narrow agent gets a guided surface. A broad agent gets the full estate. Different jobs, different tools.

AI is the engine. Judgement decides where to point it.

The cost of producing software has collapsed. The cost of producing the right software has stayed exactly where it was.

7. The Translation Layer

The translation layer is the person, or small team, that sits between business imagination and operational systems. It is the work of deciding which ideas should become real, where they should fit when they do, and which should hold for another time.

A recent example makes the shape of it concrete. The team handling profile matching inside ireckonu was under operational pressure: hundreds of thousands of possible duplicate-profile relationships to review, with a process that was hard to document. The ask, when it reached me, was to produce a very large spreadsheet of every possible match so the team could work through them. The team would have spent the same time wading through more rows. The real problem was different: classification, prioritisation, and surfacing the signals that should drive each decision.

So I built something different. A small browser script that runs inside the ireckonu portal itself, uses the portal’s own authenticated APIs, and adds decision-support UI directly into the workflow. It walks the queue, fetches profile clusters, applies transparent rule logic, and surfaces recommendation badges, candidate verdicts, supporting reasons, and field-level merge actions. It is read-only by design. All merging stays with the user. The script’s job is to help them prioritise manual review rather than wading through an undifferentiated mass.

Along the way, the script introduced something the team had been working around without naming: a category for shared booking emails, agents, and generic contacts. They knew those messy cases existed. They had not formalised them into a rule set. The script gave them a working classification.

Internal feedback was direct. One team member: “It really does make it easier to manual merge.” Users still review anything outside the auto-merge bucket. The tool is decision support; the human stays in charge. The supplier reaction was the more interesting part. When I shared the script with ireckonu, their product team was caught between impressed and uncomfortable. The customer-engineering lead said his VP “didn’t know whether to laugh or cry.” That told me something useful. The gap I had filled was a real one in their product, recognised as such by the supplier themselves.

A simpler example of the same pattern: the marketing team built a Lovable prototype of an internal check they wanted, a static view of how the tool would feel to use. They could express it precisely enough that I could turn it into a real working system. I read the prototype, questioned whether the underlying problem was actually what they thought it was, validated the shape against the data we had, and shipped it.

Both cases share the shape. The prototype is evidence. The “make me a spreadsheet” ask is evidence. Signals of what the user thinks they need, often pointing at a different problem than the one they describe.

The job is to read the signal well, keep what is true, set aside the rest, and turn the survivors into something the organisation can actually depend on.

The role itself sits in three places at once.

Part policeman, part architect, part product expert.

Policeman, because the protective work matters: keeping people clear of raw supplier APIs, choosing what to build and what to hold, channelling enthusiasm into safe directions. Architect, because each new tool either strengthens the platform or fragments it. Product expert, because the question of whether the thing is worth building remains the most important one. The translation layer works as a filter: strong ideas pass through, in a form the organisation can absorb.

8. Two Currents at Once

The work has two live currents. One is proactive: I go to a department, find a pain point, and build something. The other is reactive: someone arrives with a prototype, a spreadsheet, or a half-formed idea, and I work out whether it should become a real system. Both currents run at the same time, often on the same day.

Each one feeds the other. The proactive work creates belief: when people see something useful appear quickly, they start participating. The reactive work absorbs that participation. Each successful delivery makes the next idea more ambitious. The ideas arrive in waves, some urgent, some polished, some vague but serious, all at once.

Day to day, the work is intense. It is absorbing waves of ideas, risk, and urgency at the same time as building, debugging, and re-architecting things that already exist. Most days feel like moving in many directions at a thousand miles an hour.

The better the work goes, the harder the work becomes, because every successful demonstration creates more imagination to absorb.

That is the catch. Software appetite grows faster than the rest of the structure around it knows what to do with.

9. Dark Software

When build velocity rises, dark software becomes easier to create. By dark software I mean internal tools and automations that exist and may even be useful, but sit outside what the organisation can see, govern, document, support, or architecturally account for.

It can be a rapid internal tool. A spreadsheet replacement that only one team understands. A one-off automation. A data pull that lives only in the script that runs it. A workflow that depends on fragile assumptions only one person remembers.

Speed is fine. The argument is for being able to see what you have built alongside it. Fast development needs telemetry, documentation, and clear ownership. With those in place, the platform stays legible as it grows; the organisation can see its own dependencies.

Documentation, telemetry, and internal portals are the nervous system of fast internal software.

Once that becomes obvious, the work changes. The question becomes whether the tool is useful, and whether it can be seen, supported, and safely continued.

10. Prioritisation Under Idea Explosion

Once the loop starts, demand rises quickly. Everyone wants help. Some teams arrive with detailed prototypes. Others arrive with vague but urgent problems. Business urgency often sits with the less polished request, while the pull goes the other way.

AI-generated polish creates a new kind of prioritisation distortion. A neat prototype can feel more ready than a messy but critical problem. The polished thing reads as low-effort even when the underlying work is large; the vague thing reads as unfinished even when it matters more. Resisting that pull is now part of the job.

The work is deciding, repeatedly, which ideas to take now, which to reshape, which to defer, which to reject, which point at a missing platform capability, and which need foundational work before anything else can happen. Each decision has a cost. Saying yes to the wrong one delays the right one.

The prototype is the evidence.

The same applies to the spreadsheet, the mockup, the static view. They are signals about what someone needs. The job is to read the signal well, ignore the surface form, and decide what should actually exist.

11. What the Bottleneck Becomes

The bottleneck has moved. AI has given the people inside organisations real superpowers, and the barriers to producing software have collapsed. What sits in their place is a different question: what to do with the new capacity.

Which ideas should become real, and which should hold for another time. Where they should fit when they do. Whether the data exists yet, and whether it needs to.

That is the work the translation layer does, and AI raised its value. When the volume of ideas goes up, so does the value of someone who can read them well, decide what is worth building, and wire the result into the rest of the system.

Sometimes the right move is to expose an internal API directly to the people who need it. More often it is to translate the request into a properly hosted internal tool, integrate the data it needs, and make sure the thing actually solves the problem.

Too tight, the layer kills momentum. People stop bringing ideas. The organisation slips back into its old processes.

Too loose, it lets shadow tools proliferate, architecture fragment, supplier systems get exposed unsafely, and trust erode.

The skill is tuning it. Narrow enough to protect the platform. Wide enough to let the imagination through.

The bottleneck is where the organisation decides what gets built.

The role I am describing is becoming quietly necessary in organisations using AI seriously. It sits between what the business is imagining and what the systems already do. It decides which ideas to take on. It makes sure the ones that do can be safely depended on.

The more an organisation begins to dream in software, the more that role matters. I think a lot more organisations are about to need one.