# How I Think About Building Software in Summer 2026 > Source: [https://botensten.com/articles/building-software-summer-2026](https://botensten.com/articles/building-software-summer-2026) (canonical) > Author: Chuck — Botensten, https://botensten.com > Published: 2026-06-23 · Updated: 2026-06-30 ## TL;DR I'm on Day 327 of my live vibe-coding run. Here's what this episode comes down to: - The best software opportunities in summer 2026 are local, visible, and small — not buried in AI hype cycles. - Look for problems you can see in your own town; proximity gives you an unfair advantage over remote founders guessing at the same markets. - Vibe coding lets you validate and ship something real fast enough to test whether the problem is worth solving before you over-invest. - Ignore the headline noise about which model or framework won the week — it's a distraction from the actual work of finding and solving a specific problem for specific people. - Speed and specificity beat sophistication. A working tool for one local business beats a polished product nobody asked for. ## What is my framework for building software in summer 2026? **To build software in 2026, start with local problems — not trend reports, not model releases, not hot frameworks.** Find something broken in your own town, build the smallest version that a real person can touch, and filter every headline through that problem. That is the complete method. On Day 327 of my live vibe-coding run, I keep coming back to it because nothing else cuts through the noise as cleanly — and the historical track record makes the case plainly: Craigslist started as Craig Newmark's personal email list for local San Francisco events; Yelp came from founders who wanted restaurant picks in their own city; Airbnb started when the founders needed rent money and had an air mattress to spare. None of those began as a global bet on a trend report, and all three scaled to global scale. During my own fall 2025 build sprint, the same pattern held at a much smaller scale — the builds anchored to problems I could personally see got real user feedback faster than the speculative ones every single time. I use [vibe coding](/articles/vibe-coding-methodology) paired with a local-problem lens to stay productive rather than aimless. My approach comes down to three moves that work together: | Move | What it means | Why it matters | |---|---|---| | Start local | Find problems in your own town or daily life | Being close to the problem shortens your feedback loop | | Ship small | Use vibe coding to build fast and adjust on feel | Short cycles show you fast whether the problem was real | | Filter headlines | Use a local-problem lens on every new tool or model | Cuts noise before it costs you momentum | ## Why does starting local produce better software ideas? One approach to software ideas starts with a trend report. You read about a new market, find a gap, and build for people you have never met. That process is not wrong. But it is slow and cold. You are always one step away from the real pain. My approach is personal and geographic. I look at my own town — the businesses, the friction, the things that clearly do not work. I am inside the problem. I keep [Paul Graham's observation about startup ideas](https://paulgraham.com/startupideas.html) in mind: the best ideas come from noticing something broken in a world you already live in. Being close shrinks the feedback loop. I go deeper on this in my notes on [local problem ideation](/articles/local-problem-ideation) — specifically how to turn daily friction into a product hypothesis fast. The track record backs this up. Craigslist started as Craig Newmark's personal email list for local San Francisco events. It solved a real problem for people he could actually talk to. Yelp came from founders who wanted restaurant picks in their own city. Airbnb started when the founders needed rent money and had an air mattress to offer. None of those began as a global bet on a trend report. They started with real, local friction the founders were already living with. That local grounding did not limit them. It gave them a concrete, testable problem that turned out to exist everywhere. **How to start local in practice:** 1. Spend one week paying close attention to friction around you — businesses, services, community info, anything that takes more effort than it should. 2. Write down every time you think "this should not be this hard." 3. Pick one problem you have run into more than once. Repetition means it is real, not a one-off. 4. Ask whether software could reduce that friction for someone you could actually talk to this week. 5. Start building the smallest version that a real person could touch. ## What does "vibe coding" actually mean in this context? **Vibe coding** is a build style where you follow intuition and momentum instead of a rigid spec. You ship fast, adjust on feel, and let the work surface the real requirements. It is the opposite of waterfall. It is also the opposite of analysis paralysis. I use vibe coding alongside the "start local" idea. If I find a real problem in my town, I do not spend three weeks writing a product requirements document. I start building. The vibe-coding mindset keeps me moving. The local grounding keeps me honest. Together they give me a real shot at building something useful for a real person. My full thinking on the method is in [vibe coding methodology](/articles/vibe-coding-methodology) — including when to trust momentum and when to pump the brakes. ## Why does shipping small matter more now than it did before? At [0:00] I said: "the key idea is to start with your own town and the problems you actually see around you." The word "actually" is doing a lot of work there. "Actually" implies that most people build for problems they imagine, not problems they have seen. Shipping small is the fix. A small ship means a short feedback cycle. A short feedback cycle means you find out fast whether the problem was real or assumed. [Martin Fowler's writing on software quality and shipping speed](https://martinfowler.com/articles/is-quality-worth-cost.html) makes a related point: quality and speed are not opposites. Shipping small and shipping clean go together. The trap is shipping big and slow in the name of quality. That is where projects go to die. I ran into this tension during [my fall 2025 build sprint](/articles/building-software-fall-2025). Smaller scopes got better user feedback faster than bigger, ambitious ones did — every time. ## How do I make sense of the tech headlines without getting distracted? Summer 2026 is loud. Every week brings a new model, a new framework, a new claim about what will replace what. In the session I said I want to make sense of the headlines. That framing matters. "Making sense of" is an active, critical stance. It is not just consuming headlines. It is filtering them. My filter is the local-problem lens. When a new tool drops, I do not ask "is this impressive?" I ask "does this help me solve the thing I already know is broken?" If the answer is no, the headline goes in the noise pile. If yes, I pull the thread. I wrote about how this played out in [my fall 2025 build sprint](/articles/building-software-fall-2025). The headline-chasing temptation was real. The local-problem lens was the only thing that kept the work on track. **How I filter tech headlines without missing something genuinely important:** - Ask whether the new tool changes my ability to solve the specific problem I am working on. If yes, dig in. If no, log it and move on. - Give a headline four weeks before treating it as real signal. Most things that feel urgent in week one are background noise by week four. - Check whether builders I trust — people working on problems similar to mine — are actually using it, not just writing about it. - If I cannot map the tool to a real friction point I have personally seen, I do not act on it yet. This is also why the brainstorm format works for me. Thinking out loud forces me to name my filter rather than just apply it quietly. ## What does the "relatable" goal mean for how I communicate this? I said I want to make it relatable. That word was deliberate. A lot of software writing in 2026 targets people already deep in the stack — people who know every acronym and have strong opinions on every tool. That audience does not need me. The person I write and build for sees the headlines and feels pressure to keep up. They are not sure where to start. The "start with your own town" idea works for that person because it removes the need for prior knowledge. You do not need to know the hottest framework. You need to know your neighborhood. If you want to see what that looks like in practice, [building software fall 2025](/articles/building-software-fall-2025) documents the messy middle of that exact process. Relatable also means honest. This brainstorm was a thinking-out-loud session, not a polished argument. The ideas were still in motion. That is a feature, not a bug. It shows the real process of working something out. That is more useful than a tidy after-the-fact explanation dressed up as a framework. ## Frequently Asked Questions **Does the "start with your own town" idea only work for small-scale software?** Not necessarily. The principle is about being close to a real problem, not about geographic scale. A problem in your town might turn out to be universal — most local friction is. Starting local gives you a concrete, visible instance of the problem instead of an abstract guess. You can expand scope once the core is validated. **What if I live somewhere without obvious software-solvable problems?** Every place has friction. The question is whether you are looking. Businesses still using paper forms, scheduling that requires a phone call, community info that lives nowhere online — these are everywhere. The skill is learning to notice them instead of treating them as normal. Day 1 of that training is just paying attention for one week. The [local problem ideation](/articles/local-problem-ideation) piece has a structured exercise for exactly this. **How do I avoid building something too small to matter?** Small ships are about scope, not ambition. A small first version of a real solution to a real problem beats a large first version of a speculative one. The goal is to get something in front of a real user fast. Their feedback shapes the next version. Size scales up. A wrong direction does not fix itself easily. **Is vibe coding a serious method or just a label for moving fast?** It is both, and the tension is useful. The "vibe" part is real — momentum and intuition matter early on. But vibe coding without a grounding problem becomes aimless. Paired with a local, observable problem, it is a serious stance: ship fast, stay close to the user, let the work surface the spec. I break down the discipline behind it in [vibe coding methodology](/articles/vibe-coding-methodology). **How do I filter tech headlines without missing something genuinely important?** The local-problem lens is the filter. Ask whether a new tool changes your ability to solve the specific problem you are working on. If it does, dig in. If it does not, log it and move on. Most headlines that feel urgent in week one are background noise by week four. The ones worth your time are the ones that change your answer to a real problem. **Why is building software locally harder in 2026 than it was a few years ago?** The noise-to-signal ratio is higher than it has ever been. Every week brings a new model, a new framework, a new claim about what matters. That volume creates real cost: decision fatigue before you have written a single line of code. The local-problem lens is my answer to that cost. It gives me a fixed orientation point — a real, visible problem — that does not shift every time a new announcement drops. The hardest part of building locally in 2026 is not the tools. It is keeping your focus anchored to something real when everything around you is competing for that anchor spot. **How do I know if a local problem is worth building software for?** Three signals I use: first, I have run into the friction more than once — repetition means it is real, not a one-off. Second, I can name a specific person in my life who would benefit from a solution this week. Third, when I describe the friction to someone else, they immediately recognize it without me having to explain the context. All three together is a strong signal. One alone is enough to start a small build and find out fast. **What are the main benefits of building software with a local-first approach?** The benefits stack up in a specific order. First, you get real feedback faster — the person with the problem is someone you can actually reach. Second, you waste less time on speculative features because you can ask before you build. Third, your motivation holds longer because you can see the impact directly. Fourth, local problems tend to generalize — if it is broken in your town, it is probably broken in other towns too, which means the ceiling on what you can build is higher than it looks from the starting point. **Can I build software locally if I am not a professional developer?** Yes. The local-problem approach does not require a particular skill level — it requires proximity to a real problem. Vibe coding tools in 2026 lower the barrier to getting something working quickly. The constraint that matters is whether you understand the problem well enough to know when a solution is actually working. Being local to the problem is what gives you that understanding. The tools handle more of the implementation than they used to. The judgment about whether the solution fits the problem still comes from you. ## Frequently asked questions **Does the "start with your own town" idea only work for local or small-scale software?** Not necessarily. The principle is about proximity to a real problem, not about geographic scale. A problem you see in your town might turn out to be universal — most local friction points are. Starting local just gives you a concrete, observable instance of the problem rather than an abstracted hypothesis. You can always expand scope once the core is validated. **What if I live somewhere without obvious software-solvable problems?** Every place has friction. The question is whether you are looking. Businesses that still use paper forms, scheduling systems that require a phone call, community information that lives nowhere online — these are everywhere. The skill is training yourself to notice them rather than normalizing them. Day 1 of that training is just paying attention for one week. **How do I avoid building something too small to matter?** Small ships are about scope, not ambition. A small first version of a real solution to a real problem is more valuable than a large first version of a speculative one. The goal is to get something in front of a real user fast enough that their feedback shapes the next version. Size scales up. Misdirection does not correct itself easily. **Is vibe coding a serious methodology or just a label for moving fast?** It is both, and the tension is productive. The "vibe" part is real — momentum and intuition matter in early-stage building. But vibe coding without a grounding problem becomes aimless. Paired with a local, observable problem, it is a serious posture: ship fast, stay close to the user, let the work surface the spec rather than the other way around. **How do I filter tech headlines without missing something genuinely important?** The local-problem lens is the filter. Ask whether a new tool or model changes your ability to solve the specific problem you are already working on. If it does, investigate. If it does not, log it and move on. Most headlines that feel urgent in week 1 are background noise by week 4. The ones that change your answer to a real problem are the ones worth your time.