Just In Time Software and Flow State Building
Embracing "ugly" code and agentic mini-apps to run a hyper-optimized business.
Flow State Building
Over the past 6 months, I’ve noticed an interesting shift in my work behavior: There is no longer any distinction between when I am building with AI and when I am not.
When, even several years ago, I might start a new project with a lengthy Google Doc and project plan, today I begin with a voice dictation into Claude Code and an ideation cycle.
Together, we don’t build a document: We build a mini-app, often with some agentic features and a front-end interface. Regularly, I’ll spin up front-end interfaces only as a mechanism for me as the human to input more context in a way that’s relatable to me, then we pull it down immediately and the AI builds something better.
Each “sprint” typically takes about 20 minutes. By the end of the week, I often have built 2-3 new “mini-apps” to help me run my business. Sometimes I come back to them. But often times, they did enough for their job that week and I move onto the next. This is flow state building.
After establishing a baseline understanding of reflexive AI use, I stopped asking myself, what tasks should I use AI for? I now ask: How should I use AI?
This mental shift has completely transformed my work day. In a 40 hour work week, I consistently spend 15-20 hours of that time building (often, on multiple projects simultaneously). The rest of the time is spent in coffee meetings, workshops, and networking events.
Put another way: In the mornings I work with my AI’s. In the afternoons, I work with humans.
Getting Comfortable with Context Switching
One of the things I notice when I introduce AI no-code building to people for the first time is how the concept is received with such singularity.
People start by asking, “What’s the one app I need right now?” Then they fixate on getting one particular workflow or tool, just exactly right.
While this is a very helpful entry point, even after just one year of asking myself this question daily, I’m finding myself flourishing in the excess. Rather than build one perfect app, I’ve been building dozens of mini-apps and agents that get my work 80-90% of the way there, across nearly all areas of my work at once.
While this isn’t necessarily a “feature complete” way of building software (I obviously can’t sell a piece of software to millions of users that isn’t fully closed loop and buttoned up), it’s a perfectly fine way of running a small business or solo enterprise, where every minute counts.
Here are some examples:
The problem: Clients were paying me late on my invoice.
What I built: A semi-agentic invoice reminder system that writes me emails at the 24 and 48 hour mark after late payments.The problem: My top of funnel what running dry.
What I built: A lead prioritizer and email generator based on my LinkedIn network connections.The problem: I got very sick the day before a big presentation and wasn’t finished my materials.
What I built: An agent trained on my past workshop content and my brand that helped me immediately create printable worksheets on the spot.
Each week, I build 2-3 of these “mini-apps” or agents to help me get the job done that I need to cross of my list this week. I don’t scour the Internet for “out of the box” software solutions. I don’t outsource an engineer to build it for me. I start from the same source codebase, I describe my fresh problem, and I start a new build.
Disposable Software For Short-Term Tasks
Many classically trained engineers might turn their noses up against the idea of intentionally building my own array of mini-apps and intentionally disposable software
The code is not elegant. It is not buttery. It is polished. Many times, it is not even fully finished. But it is enough to help me move my task forward:
I send the late payment reminder.
I email 40 new pipeline prospects in one go.
I send the worksheets to FedEx to print for my session.
When I find myself calling back to the same mini-apps week after week, I invest more time in elegance, design, or functionality. Or I start to feature stack them. But if I built something three weeks ago that I don’t use anymore, I remove the interface view from my operating system dashboard and prioritize more urgent and important real estate.
The way my dashboard looks iterates in real time with me as my business grows and evolves. The source code stays the same, the saved memory and context increases. But the look of the output changes day by day, or week by week.
Make AI Work For You
For me, this exercise of flow state building is also a very meta task.
I spend most of my human-facing energy talking with organizations, executives, small business owners, community leaders, and even educators about how to make AI work for them.
Every time I unlock a new paradigm of working for myself (as a hyper-optimized AI-first founder), I’m immediately able to share it back with someone who’s earlier in the learning curve. These days, I’m spending an increasing amount of time helping teams create their own AI-first systems from the ground up that encourage cross-pollination and collaboration.
If you’re curious to learn more about what flow state building and disposable software might mean for the future of work (or you’d like to start building more yourself), give a shout at bethany@buildfirst.ai.
Love this idea and the simplicity of building mini apps. I need to think more like that -- i keep building these huge things and throwing them away.