Landon Kuhn
Illustration — Pacific Northwest landscape with Portland skyline and Mount Hood at dusk
Draft placeholder header.
Draft — placeholder content

What I actually build

Custom software isn't what you think it is. It's probably within reach.


Custom software. Two words that probably conjure a specific image: a six-month agency engagement, a hundred-thousand-dollar statement of work, a team of ten developers, a project that takes forever and comes back wrong.

That image isn't inaccurate — it describes how most custom software has been sold for most of the industry's history. It's just no longer the only option. Something has changed in the last two years that makes this conversation worth having differently than it would have been before.

The spectrum

Business software has always existed on a spectrum from cheap-and-generic to expensive-and-purpose-built. The tradeoff at every tier is the same: lower price means fitting your business to the software's assumptions. Higher price means software that fits your business.

At the generic end: Squarespace, QuickBooks, Mailchimp, Shopify. Sign up, configure, use it. Fast to start. Works well when your business happens to be shaped like what the software assumes. Becomes quietly painful when it isn't.

In the middle: Salesforce, Airtable, HubSpot, Monday. More flexible — a whole profession exists around configuring Salesforce. But still a product with a ceiling. You will eventually hit something the platform didn't anticipate, and your options at that point are bad.

At the custom end: agencies and in-house engineering teams. Built exactly for your business. Historically priced at $50K and up, with timelines to match. Reserved for companies that could afford it.

For most small businesses, the answer has always been: accept the friction. Use the SaaS that almost fits. Patch the gap with spreadsheets. Live with it.

What changed

The cost-per-unit-of-output for custom software development has dropped by roughly 5–10x in the last two years. AI tooling has changed what one experienced engineer can accomplish working alone.

Illustration — a small wizard tapping a wand over an open laptop
The honest version of how this feels from my chair: 25 years of practice, and the tool finally arrived.

Work that used to require a team of four and a six-month timeline can often be delivered in weeks now. Not by cutting corners — by using tools that have fundamentally changed what's possible for one person who knows how to use them.

This doesn't mean all software is cheap now. It means that a specific tier of project — purpose-built for a specific operational need, at small-to-medium business scale — has become genuinely accessible to buyers who were previously told to just use Shopify.

The actual competition for custom software at this tier isn't other developers. It's the buyer's assumption that custom software isn't for them. That assumption is now wrong.

What I actually build

The work falls into a few recurring patterns. Each one is a piece of what an operating business needs to run; they get combined into specific systems for specific operations.

Custom web applications. Purpose-built tools designed around how your business actually operates. Not generic SaaS bent to fit a workflow it wasn't designed for. This might be an order management system, a customer portal, a staff-facing operations tool, or something that doesn't map cleanly onto any existing product category.

Workflow automation. The thing you do by hand every week — reconciling spreadsheets, copying data between systems, sending follow-up emails — turned into something that happens automatically. This is often the highest-leverage work: hours saved weekly, permanently.

Data integrations. Connecting the tools you already use. Getting your CRM to talk to your billing system. Getting your e-commerce store to sync with your fulfillment operation. Replacing three tools that don't talk to each other with one system that does everything.

Dashboards and reporting. Seeing your business clearly. Real-time data. The metrics you care about, updated automatically, without asking anyone to pull a report.

Progressive web apps. Mobile-ready applications that install on any device without going through an app store. Fast, works offline, available on whatever device your staff or customers are using.

Worked example: a Portland cart pod

Illustration — a Portland cart pod at dusk: a row of food cart trailers under string lights, customers at a picnic table, evergreens behind, kitchens visible inside the carts
The pod is already a place. The system that makes it feel like one — for the customer, for the operator — isn’t built yet.

Imagine a cart pod on the east side. Six vendors. Wood-fired pizza, Vietnamese, halal, ice cream, a bagel cart, a coffee cart that does breakfast burritos. Each vendor takes orders their own way — some on Square, one on a paper pad, two through their own websites that nobody visits. The pod has a name and a sign on the gate, but to a customer scrolling Instagram looking for somewhere to eat, the pod doesn't quite exist. Five separate cart pages do.

The pod operator wants the pod to be a place. One menu spanning all six vendors, browsed and ordered from the same screen. One payment flow. One loyalty program. Customers pick up at whichever windows they ordered from. Vendors get tickets on a kitchen display, keep their identity, stay focused on their food. The operator handles the operational layer in exchange for a cut.

This is custom software. Specifically:

A vendor portal. Each vendor signs in, pushes their menu, marks items 86'd in real time, sets prep windows for the day, opens or closes early without phoning the operator.

A customer storefront. A unified menu across all six vendors. Browse, mix items from multiple carts into one order, pay once.

Order routing. Orders split by vendor and sent to each vendor's kitchen display. Pickup timing coordinated across vendors so the customer doesn't wait at the pizza window holding melting ice cream.

Payment splitting. One charge to the customer. The pod takes its operational cut. Each vendor settles to their own account on a known schedule.

The pod's brand. The whole experience — discovery, browsing, ordering, pickup — happens inside something the operator owns. For any customer who isn't standing on the gravel, the pod's portal is the pod.

AI threads through, where it earns its place. A customer enters “something not too spicy with rice and a coffee for 3pm pickup” and the system suggests a coherent cross-vendor order. A vendor types “no more pho, switching to bun cha for the rest of the day” and the menu updates without clicking through forms. The operator asks “what was last weekend's slowest hour” and gets a real answer from the data. None of these is a chatbot. They're small, specific uses of AI inside a system that mostly runs on plain code.

None of this is exotic for someone who's built operational systems before. It also isn't what off-the-shelf tools were built to do. The big players in restaurant software build for chains, where the unit economics for a SaaS company work out. Cart pods get scraps. The pod doesn't get this kind of software because it's hard to build — the pod doesn't get it because no SaaS company is going to build it for a market this small.

That's the gap that just changed.

AI as a layer, not a feature

AI is part of how custom software gets built in 2026 — not as a chatbot widget, not as a separate offering. It's a layer inside whatever system you're building, doing specific jobs where it outperforms hand-coded logic.

The judgment is in knowing where AI helps and where it makes things worse. A scheduling constraint solver should not be an LLM. A natural-language interface to that constraint solver absolutely should be. Most of the useful AI in custom software lives in that second category — a small, specific layer doing a specific job, surrounded by deterministic logic that's been working for decades.

Concretely: classification of unstructured input, summarization of long documents, structured extraction from PDFs and contracts, fuzzy matching, intelligent suggestion, natural-language interfaces to otherwise-rigid systems. Each of these is small and well-defined. None of them replaces the rest of the software; they fit inside it.

This matters because the alternative — wholesale “AI for your business” offerings — usually fails for one of two reasons. Either the AI is doing too much and the system is unreliable, or the AI is doing too little and the “AI” is a thin chatbot widget grafted onto a stock product. The middle path — algorithmic where algorithms are right, AI where AI is right, integrated cleanly — is what custom software in 2026 looks like when it's built well.

What I don't build

[Placeholder — reference the fit section and be honest about what's out of scope.]

Standard five-page brochure sites — that's Squarespace, and Squarespace is the right answer. Venture-backed product startups — different model entirely. Projects requiring deep compliance infrastructure (HIPAA, PCI at scale) where solo delivery isn't the right risk profile.

The question worth asking

The question isn't whether custom software is for you. The question is whether the friction of your current software is costing you more than it would cost to fix it.

For small businesses, the answer is more often yes than people expect — and the gap between "what it actually costs now" and "what they assumed it would cost" is usually why they've waited this long to ask.

← Back to home The discovery week → Retainer economics → Why this is possible now → This vs. a website → The neighborhood shop →