How to Build a Working Software Tool for a Few Dollars

Claude Haiku 4.5 landed at around a dollar per million tokens, and that price changes who gets to build software

The cost of building a real software tool just fell below the price of lunch. Claude Haiku 4.5 is priced at roughly one dollar per million input tokens, which means an afternoon of genuine software development, planning, coding, debugging, and shipping a working proof of concept, costs somewhere between two and ten dollars in total. That is not a marketing figure. It is the measured cost of actual sessions that produced actual tools.

I am Madhuranjan Kumar, and I want to make the significance of this concrete rather than abstract. The population of people who could build software has historically been defined by two gates: skill and money. The skill gate is the more famous one. You needed to know how to write code, configure environments, and debug errors without guidance. The money gate was less discussed but equally real. Commissioning a developer to build a small internal tool meant spending between one thousand and five thousand dollars for something basic, and that price excluded most small business owners from custom software entirely. Haiku 4.5 does not eliminate the skill gate, but it makes it porous. And it effectively eliminates the money gate. At one dollar per million tokens, you can make mistakes, restart, try a different approach, and still finish the day having spent under twenty dollars. That changes the economics of trying an idea.

The fast speed of the model also matters in ways that are easy to undercount. When a coding assistant responds in seconds rather than tens of seconds, the rhythm of building changes. You stay in the problem instead of losing focus during the wait. The sessions that produce working software are the ones where you build momentum, and momentum requires that the feedback loop is fast enough to feel like a conversation.

The timing of this release matters beyond the price. The context window is large enough to hold a real codebase during a session, the reasoning is solid enough to debug non-trivial errors without constant hand-holding, and the speed is high enough to keep a builder in flow across a full afternoon. Those three things together, price, context, and speed, are what make the model a practical tool for a non-technical business owner rather than a toy for a developer who already knows how to build.

The plan-first step is what separates people who ship from people who get stuck

Every experienced developer knows that planning a project before writing code is the difference between a project that ships and one that gets lost in revisions. The same principle applies when you are directing an AI model to build something, and the stakes of skipping it are actually higher with AI than without, because the model will confidently build the wrong thing and produce a polished result that looks right until you try to use it.

The right starting point is what experienced AI coding workflows call plan mode or architect mode. Before a single line of code is written, you work through a set of clarifying questions: what does this tool need to do, what does a user interaction with it actually look like step by step, what are we deliberately leaving out of this first version, and what is the simplest possible technology stack that could produce this result. The questions sound basic and they are basic, which is exactly why skipping them costs so much time. A vague brief produces software that technically does something and practically does nothing you needed.

The other critical planning decision is stack simplicity. Every additional technology layer is another surface for errors. A first version of an internal tool should use the most standard possible approach: a simple server, a plain file for data storage in early stages, and one screen that shows the information you need. You can add complexity after the idea is proven. The model builds whatever you describe, so if you describe a simple system, it builds a simple system that is easy to debug. If you describe a complex one because it feels more impressive, it builds a complex one that produces more confusing errors when something goes wrong. The planning step is where you consciously resist the impulse to make the first version sophisticated.

There is a second discipline the planning step enforces: deciding what the tool is not. Every useful tool has a feature list that starts short and grows. The trap is starting with a long feature list and building a tool that is half-finished everywhere instead of complete somewhere. A tool that does one thing completely, quickly, and reliably is more valuable on day one than a tool that almost does five things. The plan-first habit forces this scoping decision before any code exists, which is why it is the most reliable predictor of whether a build session ends in a working tool or in frustration.

A practical method for the planning conversation: tell the model what problem you have, then ask it to propose the minimum feature set that would solve it. Review the proposal and cut anything that is not strictly required for the first version. Only after you have agreed on that reduced scope should you ask the model to build. The entire planning conversation typically takes twenty to forty minutes and saves three to five times that in debugging and rework.

A property management firm built its own lease-renewal tool for eight dollars and recovered fifteen hours a month

I want to walk through a concrete example because the abstract economics only become meaningful when attached to a real workflow.

A property management operation was losing fifteen hours per month to a single manual process. Every sixty-day window, someone pulled the upcoming lease renewals from a spreadsheet, checked each one, drafted a reminder message for each tenant, and sent them individually. The process was not complicated. It was purely repetitive, and it required a person because the data lived in a spreadsheet that nothing else could read automatically.

The owner used Haiku 4.5 to build a tool to replace that process. The planning stage took about forty minutes of back-and-forth with the model to define exactly what the tool needed to do: read the lease data, identify renewals coming up within sixty days, draft a reminder message for each one using the tenant's name and the specific renewal date, and output them in a format the owner could review before sending. No automatic sending. No interface beyond a simple list. One screen, upcoming renewals, and a draft message for each.

The build took one session. The model wrote the logic, connected it to the spreadsheet format the firm already used, and produced a working tool. There were three rounds of debugging. Each one was handled the same way: read the error message, ask the model to explain what caused it before asking it to fix it, then apply the fix and test. Total API cost for the session: eight dollars and change. The firm now runs the tool once a month, reviews the drafted messages, and sends. The fifteen hours per month became ninety minutes. At a conservative internal rate of twenty-five dollars per hour, the monthly labor saving is approximately three hundred and thirty-seven dollars. The tool cost eight dollars to build and nothing to run.

Two things from this example deserve emphasis. First, the scope was kept tight deliberately. The owner resisted the idea of adding automatic sending and a tenant portal in the first version. Both features were noted for later. Building them in the first version would have added cost and debugging time and would have introduced the risk of a message going to the wrong tenant before the system was properly tested. Second, the debugging was calm and sequential. When errors appeared in sequence, each one was addressed individually, understood before being fixed, and tested before moving to the next. The patience to do that is not a technical skill. It is a discipline that any person can apply regardless of their background.

The tool is not sophisticated. It is exactly as capable as it needs to be to replace the work that was consuming fifteen hours. The value is not in the sophistication of the software. It is in the fact that the software exists and the fifteen hours do not disappear into it anymore. At eight dollars to build, the payback period was measured in the first use.

Caching is the multiplier that makes the cheap model cheaper the longer you run it

One dollar per million input tokens is the base price. Caching brings the effective cost of a sustained development session significantly below that base.

Here is how caching works in practical terms. When you work with an AI model on a coding project, a large portion of each request is context that stays the same across messages: the files you are working with, the instructions you gave at the start of the session, the code that already exists. Without caching, the model reads all of that context fresh on every single request and charges the full input price for it. With caching, that repeated context is stored and read back at a fraction of the full price, often around ten percent of the base input cost.

The math compounds quickly over the course of a session. If you are fifty messages into a debugging session and the tool's existing code is part of every request, you are paying ten percent of the input price for that code on every message after the first few. A session that would cost fifteen dollars at full price for every token costs closer to five dollars once caching runs through the repeated portions. The longer the session and the more structured the code, the larger the discount becomes.

The practical implication is that investing time in clean, well-organized code at the start of a build pays back twice: it produces code that is easier to debug, and it makes the repeated context more compressible for the cache. A messy codebase repeated across sixty messages costs roughly the same as a clean one repeated across sixty messages at full price, but it costs more to debug and harder to read, so it ends up consuming more messages to fix the same problems. Clean structure is both a quality investment and a cost investment.

For businesses that build tools and then continue to improve them over weeks, caching is especially significant. Each time you return to a project, the existing code base is cached context, and you are reading it back at a fraction of the base price. The effective cost per improvement session drops the longer the project runs. A tool that cost eight dollars to build in the first session might cost two dollars to improve in the fifth session, because the codebase is large and familiar and caches efficiently.

Two specific practices maximize cache effectiveness. First, begin every session by loading the full codebase into context before asking any questions, so the cache populates on the first message rather than partway through. Second, structure the code into clearly separated files rather than one large file, because modular structure tends to cache better and makes it easier for the model to understand which parts of the code are relevant to the current task without reading everything on every call.

The bottleneck has moved from budget to idea quality

The accessible way to understand the current moment is this: the constraint on who gets to build software has shifted. Budget used to be the primary constraint. Now it is idea quality and execution discipline.

This shift is not incremental. Two years ago, a non-technical business owner with a useful idea for a small internal tool had three realistic options: spend one thousand to five thousand dollars on a developer, pay a monthly fee for a no-code tool that did not quite fit, or shelve the idea because the numbers never made sense. The threshold that converted an idea into a real software project was genuinely high, and most ideas did not clear it.

At one dollar per million tokens with caching, that threshold is effectively gone for small internal tools. A motivated owner can turn a clear idea into a working proof of concept for the price of a dinner. The question is no longer whether you can afford to try an idea. The question is whether you have a clear enough idea and the patience to debug one error at a time.

The two constraints that remain are both within the individual's control. The first is the quality of the idea itself: is there a specific workflow with a real time cost that a specific tool would replace? Vague ideas produce vague tools. The ideas that work are the ones attached to a specific recurring task with a measurable cost. The fifteen-hour-per-month lease renewal example worked because the problem was concrete. There was a specific set of inputs, a specific desired output, and a specific frequency that made the labor cost obvious.

The second constraint is execution discipline, and the most important element of that discipline is the plan-first habit. The owners who build working tools are the ones who define scope before touching a model. The ones who get stuck are the ones who start with a vague ambition and expect the model to guess what they need.

The competitive dynamic this creates is worth naming. In most local markets and most industries, the business that starts building AI-driven internal tools this quarter will have a meaningful operational advantage over competitors who wait. The tools themselves are modest. A lease renewal tool, a quote builder, a lead intake form, these are not transformational products. But the hours they recover are real, and the advantage of having more of those tools compounding across a business grows over time in ways that are hard for a later-starting competitor to catch up with quickly.

The most useful thing I can tell you about this moment is that the economics are not going to improve dramatically from here. The price is already low enough that it should not be a deciding factor. The decision is whether you are going to be the business that started building when the tools were cheap and accessible, or the one that waited until the market caught up. The first type builds operational infrastructure early. The second plays catch-up against competitors who already have it. The gap between those two positions grows with every quarter that passes, and it started widening the moment Haiku 4.5 priced itself at one dollar per million tokens.