What's Underneath by Yoshinao Takisaka

What Completes Software ― Pain-Driven Software Development

On what refuses to ship in an age when AI can build anything

Claude Code is spitting out code across the CLI. Files keep appearing on my machine, one after another. It was my first macOS app. Despite stepping into unknown territory, I didn’t hit any major stumbling blocks. In just a few hours, a prototype took shape.

I built an app that visualises meeting speech in real time, structuring it as people talk. I named it “CONTXXXT”. Facilitation—organising and guiding a discussion—is part of a consultant’s toolkit. I wondered if software could do this. The app transcribes meeting audio in real time and structures it on screen like a flowchart or treemap. It was meant to be an AI version of a graphic recorder, capturing the conversation as it happens.

The tech stack: WhisperKit and Apple Speech for voice recognition, a 3-stage LLM pipeline (realtime / mid / final) using Gemini for structuring speech, and ReactFlow on a WKWebView for graph rendering. It’s a native macOS app running on a combination of Swift and TypeScript.

Technically, it reached an MVP (Minimum Viable Product) surprisingly smoothly. Speak into the microphone, and nodes spawn on the screen one after another. Lines link their meanings, and the conversation structures itself.

Watch the video on Substack →

CONTXXXT in meeting mode — speech is structured into nodes in real time

Seeing my own words instantly diagrammed felt like magic, even to me — and I’d built it. I thought it might actually be quite useful. Riding that high, I tried it out in a real meeting with a few colleagues and friends.

That’s when I noticed a fundamental problem.

When structured speech is constantly visible on screen, it steals your attention. Everyone’s eyes end up chasing the branching graph. You get distracted thinking, “Oh, it’s drawn it like that now,” and the actual substance of the discussion doesn’t sink in. A conversation should be carried by faces and tones. Instead, attention gets pulled into the shifting shapes on the screen. A tool meant to smooth out discussions was actually getting in the way.

Then it dawned on me. Graphic recording isn’t something you stare at continuously during a meeting. Its value lies in providing a bird’s-eye view of the whole picture once the discussion is over. Constantly visualising it in real time came with a fundamental trade-off: scattered attention. It defeated the entire purpose.

Technically, it worked. As a bystander watching the meeting, it’s interesting. But for anyone actually trying to use it to smooth out a discussion, it just gets in the way. The benefit of “this looks cool” was far too small. There was no user pain there. Realising there was no point in taking it further, I stopped development.

There is a gulf between “what works” and “what’s indispensable”. AI lets us build what works, but it doesn’t bridge that gulf. It made me realise that no matter how advanced the technology, or how quickly it takes shape, whether it truly helps people is an entirely different story. It has to resolve pain.

(Learning how to create macOS apps with Xcode and Swift was extremely beneficial, though.)

Another project, and its conclusion

Around the same time, I built another project using Claude Code, and this one I saw through to the end. It’s a clone of voice-to-text tools like Superwhisper and AquaVoice. I named it “HyperWhisper”. It transcribes audio from the microphone, applies whatever formatting you want, copies it to the clipboard, and pastes it. It’s just a simple macOS app that does exactly that.

The tech stack: on-device transcription via WhisperKit, and lightweight formatting (bullet points, summaries, converting spoken to written language) via Gemini Flash. Like CONTXXXT, it’s written in Swift, but the UI is stripped back to the absolute minimum.

Why did this one cross the finish line? The reason was clear. Its value was already defined in the market. I didn’t have to invent it from scratch. There are plenty of similar tools out there, and people find them useful. I could entirely skip the hypothesis-testing phase of wondering whether anyone actually needed it.

Even more importantly, it solved my own pain. I use voice-to-text tools heavily on a daily basis. I dictate ideas while walking, or draft long texts by speaking them aloud. Over time, I’d grown frustrated with existing tools. They had too many features I didn’t use, or failed to scratch a specific itch. I stripped away the bloat and added exactly what I wanted. I’d rewrite the code, use it, and fix it as I went. That self-improvement loop turned beautifully.

As implementation progressed, I felt a solid sense of achievement. Because I was the user, I knew exactly what would satisfy me. If I thought, “I wouldn’t be so annoyed if the processing speed were just a bit faster,” I fixed it. I’d try the fix and nod. “Yes, this feels right.” Even if the product’s core value was borrowed from an existing market, the tactile sensation of completion was undeniably there.

Only the features I want, exactly where I want them. And I built it myself. The IKEA effect. When I reached the point where I felt it was good enough, I naturally took my hands off the keyboard. That was, without a doubt, one form of completion.

Where Pain resides

Same creator, same tools. One finished, one stalled. The only difference was whether I had defined whose pain I was solving.

I’ll call this approach “Pain-Driven Software Development”. It is a style of design and implementation that takes pain, not gain, as its starting point. Before specifications or feature requirements, there is pain. Because there is pain, you know what to build. You know what to discard. And you know exactly when to call it complete. Necessity is the mother of invention.

Of course, it’s fine to be curiosity-driven at first. You can’t see certain things until you get your hands dirty. New technology and the thrill of building something cool are the driving forces of creation. But if you want to take a project all the way to completion, curiosity must eventually give way to pain. Whose pain are you taking on, and what kind? I have countless projects slumbering in folders, stalled at the 80% mark, because I never answered that question.

Things built to solve a clear, urgent problem naturally head towards completion. The goal is obvious. You can picture the person using it, which gives you the motivation to iron out the details. You handle edge cases and write documentation because you have a reason: “They’ll get stuck here,” or “I want to help them.” It’s the same when the pain is your own. The urgent desire to remove a daily inconvenience pushes you through those final, tedious adjustments.

By contrast, projects started simply because they look technically interesting stall at the 80% mark. The moment the core functionality works, satisfaction sets in. A graph is drawn on the screen. Voice turns into text. Curiosity is satisfied by the mere fact that it works. The energy to tackle the remaining 20%—handling unexpected errors, fine-tuning usability, security measures, testing, and all the unglamorous work leading up to a release—suddenly dries up.

In the AI age, the cost of writing code has dropped dramatically. You can shape an idea the very day you think of it. But the cost of completion hasn’t changed. If anything, because starting is so easy, we are mass-producing unfinished projects. Completion does not visit a place without pain. Without the resolve to imagine someone’s pain and take it on, you cannot run that final 20%.

The kitchen had a quality threshold

When I think about the difficulty of finishing things, I recall my time standing in a kitchen as a chef.

As a professional, you never serve a half-finished dish. If you’re going to make something, you want the customer to be entirely delighted. That is a craftsman’s instinct. Flavour hypotheses conceived in your head often turn out completely different when you actually cook and taste them. Ingredients might clash, or the heat control might be tricky. Noticing that gap and correcting it is the professional’s job.

Even so, in a real kitchen, constraints pile up. In a fully booked restaurant, order slips line the rail. You’re plating an appetiser, keeping a side-eye on the grill, and checking the roast in the oven. You have to make everything simultaneously, in large quantities. Time, ingredients, and the logistics of orders intertwine, inevitably causing fluctuations in quality.

Say you’re making five plates of the same dish at once. You toss the pan and coat them in sauce. Four plates are perfectly finished, but the fifth doesn’t quite sit right with you. Do you serve it, or not?

There is a threshold of pride there. Where do you draw the line of compromise? It fluctuates depending on the situation and how busy you are. The faces of the waiting customers come to mind. You’re running low on ingredients. If you start over now, the rhythm of the entire service will collapse.

Caught up in the rush, or constrained by time and ingredients, I’ve sometimes compromised on quality. The result? The owner sends it back with the silent pressure of, “How can you serve this?” The plate is returned, and you get a customer complaint. Anyone who has worked as a chef has surely experienced this.

Completion is the moment Pain is resolved

So what is completion in software development? It is the moment someone’s pain is resolved, and they reach satisfaction.

If you’re building for someone else, you build until they are satisfied. If you’re building for yourself, you stop when you are satisfied. If it’s a commercial product, you raise it to a quality where the market accepts it as an MVP and people are willing to pay for it. The line of completion is determined by complex constraints like time, budget, and technical limits. It’s just like cooking: knowing whose face you’re cooking for naturally determines how far you should reduce the sauce.

A project driven solely by curiosity can be developed forever. AI accelerates development, but it also tempts you to add feature after feature. “You can implement this too,” or “It’ll be richer if you use this library.” The temptations expand infinitely. Watching AI suggestions scroll across the terminal, it’s easy to get carried away. Features disconnected from the core essence swell up, and the work never ends.

To cut off this temptation and head towards completion, you have to use the software early on, in its intended scenario.

When Claude returns code saying, “It works up to here,” you need to test it yourself. Gauge whether the MVP feels satisfying. Hit the keyboard, move the mouse, watch the screen react. Notice the snappiness of the operation, the readability of the information, the tactile feel. No matter how brilliant the AI behind the screen is, only my physical sensation as a user can judge where satisfaction lies. AI writes the code, but it doesn’t teach you the feeling of “this is enough”.

Once the target of satisfaction is clearly defined, and you judge that the software has hit that mark, it is complete. It might be your own internal sense of “this is good,” or the words “that helped” from someone right in front of you. When you get that tangible response, the software finally reaches a milestone.

A product’s philosophy resides in the details

The criterion for completion is not merely the fulfilment of features. The creator’s values and philosophy are heavily reflected there too.

Take the gender field on a web form. Do you write it as a male/female binary, or make it a multiple-choice including “other”? Do you make it a free-text field, or simply not ask for gender at all? This is not just a technical choice. It is an expression of the values held by the developer and the service provider. Thought and philosophy are expressed implicitly, left behind as a marker.

I’ve had a similar experience myself. As a web developer, I had a strong interest in accessibility. The reason was simple: I have many friends and acquaintances with disabilities.

Even when my company or the job didn’t require it, I worked with a strong awareness of accessibility. I’d adjust the reading order for screen readers, check colour contrast, and rewrite code so every operation could be done with a keyboard. Accessibility is easily overlooked in some industries, and clients rarely ask for it. But as a matter of personal philosophy, I set my own completion criteria for how far to support it. Holding my own yardstick, I implemented it as a matter of thought.

Why do it when no one is asking for it? Because the faces of my friends determined where the pain resided. “When that person tries to use this site, they might stumble here.” Because a specific face comes to mind, I can’t cut corners.

When pain is given from the outside—a customer request, a boss’s instruction, or a legal obligation—a borrowed criterion for completion is fine. Tick off the checklist, and you’re done. But when you discover and take on the pain yourself, you have to establish the completion criteria within your own philosophy. How far is enough? Where do you compromise? Those choices are left as markers of the creator in the details of the service—in the gender field, in the depth of accessibility support. In every single line of code, what we see and what we value is engraved.

The creator’s philosophy remains as thought

In the AI age, we really can build anything. We can shape an idea in a matter of hours. Precisely because we have this magic-like tool, what we choose to take on—and what we give up—becomes our philosophy.

Products and services are meant to resolve someone’s pain. Who are you building it for? Whose pain do you want to ease? Can you picture their face, nod, and say, “I can send this out”?

Can an AI — one that feels no pain, no suffering, no inconvenience — truly develop a product in the deepest sense of the word? Doesn’t the design and implementation still need a human to breathe thought and philosophy into it? Software holds thought. Philosophy resides in it.

What pain — and whose — is the starting point of the product or feature you’re working on right now?

Thanks to AI, whatever we think of can immediately take shape. Because of that, the issues you stay sensitive to—and how far you are willing to reach—naturally bleed into every single product.

In this blog, I write true-to-life accounts of the indispensable role humans play in creation during the AI age. If you’re interested, please subscribe via the button below. Next time, I’ll be sending out a self-introduction post, laying out exactly who I am and what this series is exploring.

Thank you for reading to the end.

What is a product or feature you wanted to finish, but stalled at the 80% mark? If you’d like, please let me know in the comments.

If this piece resonated with you, I would be delighted if you liked or shared it.

The Thinking Behind

I want to leave here the concepts, philosophies, and tools that run like an underground vein beneath this argument, even if I couldn’t unpack them deeply in the main text.

Tools and references mentioned in the body:

Concepts not unpacked in the body, but underlying the argument:

※ This piece is based on my (Yoshinao Takisaka’s) lived experience, deepened through AI-assisted interviewing, and composed in collaboration with AI. Powered by Gemini and Claude.

※ The video in this piece captures the actual behaviour of CONTXXXT, an app I built.

Suggested tags: #AI #LLM #SoftwareDevelopment #ProductManagement #Engineering #DigitalTransformation #AITransformation #Craft

Substack version