The Casual Coder

This was cross posted from Linked.

Although I haven’t been a full-time developer for well over 25 years, most of my career in product leadership has been in support of people building, deploying, and managing software systems, so I’ve always maintained a close interest in the art and science of software. With only a few exceptions—pretty much every year for the last 25 – I’ve managed to find a reason to actually write some code. I’m a big fan of learning by doing.

The early AI augmented co-pilots were very useful for someone who, like me, is not a regular coder and doesn’t have the time to learn the latest language, framework, or stack. The first vibe coding platforms were even more useful—producing running prototypes from simple prompts but the tools quickly became confused after a few iterations.

In the last 6 months, though—I feel like we’ve hit a significant step change in capability. On rainy Memorial weekend this year, I jumped into full AI development using Claude Design/Code, and I am pretty blown away with the speed and results.

Over the last 3 days, I developed two non-trivial apps—both of which would’ve taken me months to hand-code. Note in aggregate – I suspect I only spent about 5 or 6 hours actually developing software.

The work-related app

This first (A11yBot) is a web-based tool for completing Accessibility documentation (aka VPATs)—something most government customers require but part of the “whole product” that is usually de-prioritized. Yes, there are commercial apps, open-source apps and even commercial services for producing A11y report – but that’s not really the point – it’s a rich enough space to make a good target app.

The A11yBot app runs locally, scans source code and a running web apps, and produces a VPAT report covering the standards you have selected. AI-generated responses synthesize the evidence from scans and completes the report. It supports the major Accessibility standards in the US and internationally. You can plug in an LLM for the AI response generation using OpenRouter or hook up to local models using Ollama APIs.

For this app – I started with a two-page-long specification outlining the MVP, goals (as automated as possible), and constraints (easy to run locally). From that, I asked Claude to produce a design – schema, workflow, and technology stack. Got the first working release in about 30 minutes and pushed it to GitHub as a baseline.

Running local models, scanners, test environment, and builds on a 24Gb M5 MacBook doesn’t work well, so I invested time in using the remote option in Claude Code so everything is running on a bigger Mac mini in my office. I have a suspicion that Claude leaks Chrome helpers as well – ended up with hundreds consuming about 70Mb each. Reboot time.

I also spent time trying different local models (via Ollama) for the report generation, then had Claude implement an OpenRouter API so I could use larger text models – huge improvement in speed and quality. Tldr – the big hosted models are a) much faster; b) produce much better outputs. You pay for what you get.

After several iterations – the app functioned well but looked like crap, so I opened Claude Design, asked it to do a design review (just needs access to code), and then to come up with a better design. Also added a dark mode switcher and took care of some outstanding A11y issues. It took about three more sprints (maybe 2 hours in total) to get all this work done, which required some restructuring and updates to the underlying data model, but this phase truly left me impressed. I realize Claude Design is still new, but it can already do some impressive work – I need to invest more time. Once Claude Design is fully integrated with Claude Code – it will be incredible – for now you just have to copy whole design briefs over and have Claude Code ingest them.

The A11yBot project is available on GitHub under – feel free to take it for a spin. If enough people are interested – I’ll invest more time in it and push it to npmjs to make it even simpler to run and probably license it under ASL2.0. Likewise – if anyone wants to improve on it – bring your robots !

The lifestyle app

The next app came off the long list of apps that I wish existed. I’m a bit of a home Espresso aficionado and go through a manual process of dialing new beans (dose, grind, extraction time, etc.) – the science/logic is well established, but I’ve never seen a decent application to make it easier.

Unlike the first app, I had a very good sense of how the app should behave, so I started in Claude Design (oops, ran out of credits) rather than diving straight into code gen. I started with a one-page specification describing the manual workflow and form factor – iPads, iPhone, and the areas I thought could be improved with an app.

MVP is:

loading a new bean – scans QR code and pulls details from the roasters’ website, or you can enter details manually.
Maintaining your Bean database (hopefully with the perfect extraction parameters).
Running an extraction, recording parameters like dose, grind, time, etc.
Taking user input on taste and giving advice on how to improve the next extraction.

I handed over the Design spec to Claude Code – asked it to come up with a schema and technical design and then let Claude go in full auto mode (oops, out of credits again).

I had to do a fair amount of debugging and research with this one (maybe 30 – 60 mins.) – especially the QR code reader. And I had to do two extra test shots to get the flow right – buzz!. I’m not making this repo public for now – need to iterate on it some more but may share it in the future. I also think this App will scale up well – the more people use it the more data on perfect extractions will be available without the need for experimentation.

Lessons Learned

A few things I’ve learned through this long weekend exercise:

For anything but minor fixes – do focused design / plan session – that gets you down to a very specific plan and goes much quicker
Maintain a regression suite. After major revisions, ask Claude to update regressions tests – I mostly do this for the data layer and APIs. Also, have some baseline reports to black box test end to end.
As long as I’m working on my own, I’m just working on the main branch though I’ve used feature branches for more speculative / risky stuff. Right now, I’m just letting Claude deal with GitHub.
Experiment in branches – code is now cheap – if the change doesn’t work, abandon the branch.
To do any kind of development, you need a $200 / month plan – I’m guessing full time devs are burning through $1000’s a month ??
Ask Claude to delegate visual testing back to you – watching Claude do testing via Chrome with screenshots is painful and very slow and no doubt burns tokens
Cost aside – code is cheap. I did start logging issues in GitHub for future work but quickly realized it takes only a little more (of my time) to ask Claude to code it.
If you have multiple machines – there are various ways you can leverage them – I’m using SSH to run stuff on my Mac mini while working on my laptop.
I find working in focussed sprints much quicker and less likely to exhaust / pollute the context window (mine and Claude’s!).
Batch up small fixes into a single prompt. This fits with how I work – I’ll run through the flow and make notes then ask Claude to fix them before the next iteration. Bigger stuff goes into a separate sprint.
Use /clear regularly – I use /clear as a matter of course when I’m starting a new “sprint”
The collapsed feedback loop is a true game changer – you can sit down with a user (myself included, in this case) and iterate in real time.
I’ve become acutely aware of token costs and have already started reading tips on token frugality.

Note – I’ve used the word sprint here – to me that’s a focussed batch of work with some outcome but instead of taking 2-3 weeks – it takes between 5 and 15 minutes with Claude.

In a previous life, I was a developer for about a decade – Assembly, C / C++, Fortran, Smalltalk, Java, I used to love developing software – you get a real sense of accomplishment but I never had the patience for the yak-shaving, obscure language syntax or arcane behaviors of someone else’s framework. Removing coding tasks from software development has been a dream for decades but we’re getting dangerously close to finally achieving it IMO.

Introduction

Defining and launching a product successfully without making at least some changes during the product development lifecycle is rare. Or, more likely – product leaders who are willing and able to adapt their product plans as they gather feedback during product definition and execution are more likely to succeed.

Product Market Fit (PMF) is used to assess whether an offering has found its place in the market (i.e., solves real problems users have) and can support a sustainable business.

PMF isn’t just a one-time check – it is something you must do continuously, even after you have shipped a product and have seen some success. User needs rarely stay static, and successful products and companies see the signals of change and adapt.

The Stages of Product Market Fit

The sooner you can determine good PMF, the sooner you will have the confidence to invest and build. Unfortunately, the PMF signals start weak and strengthen only as you get closer to a released product.

Once you have made an initial product available to customers (Prototype, MVP, Beta), your signal strength increases significantly, but so does your cost and resistance to change.

Generally speaking, there are things you can and must do before you build the product and things you should do once you have shipped something to continuously monitor whether you are still relevant to the market.

Market Validation and Sizing

The first step is to validate that there is a market for the solution you are thinking of. If you’re doing something truly disruptive and creating a new market – this will involve talking with people you believe have the problem you are trying to solve – you are trying to validate a concept. You will also need to size this market to understand the potential or TAM (Total Addressable Market) to determine if there’s a real business in solving the problem.

If you are not a true market-maker (more common), it will be much easier to determine the market potential – you may have established competitors, open source projects, or industry consensus that will validate the market need and potential size.

Pre-product

Once you understand the market and the personas involved (users, buyers, influencers), you can start to validate whether your proposed solution and its USP (Unique Selling Points) will address the market need. That validation will likely consist of one or more of the following with increasing fidelity:

User/customer feedback on concepts
Testing the USP and Value Proposition with users/customers
Formal testing with wireframes, early prototypes, etc.
Canned demos to start explaining some of the behavior to users
Pre-GA releases – the sooner you can get the working product (in some state) into the end users’ hands – the better.

The challenge at this stage is finding the right users/personas willing to commit time and provide feedback – incentives (service credits, free access to the final product, etc) may help.

During this stage, you will likely learn more about your target users and may even have to re-consider your target personas in light of what you learn. The feedback you receive may also require you to change how you talk about the product and may need to refine and refocus your USPs.

Post-product

As I mentioned at the top of the article – the PMF signals get stronger the closer you get to a released product, and until the user can try the product in-context you may still need some critical validation. There are many factors aside from the core product that can affect user acceptance and validation:

Price – you may have validated PMF in the context of a free offering. Putting a price on something changes how the user thinks about the product.
Form – you may have validated the offering as a standalone feature (vs embedded as part of a platform) or a software vs service or dedicated hardware device.
Availability – your procurement and onboarding process may add additional friction unacceptable to your target user/buyer.
Market Access – you may have engaged with some initial target users, but does your salesforce/ sales channel give you access to the market you need?

Just because you have shipped a product and found at least some success validating PMF – don’t stop listening to the market and your customers/users. This is where tools like NPS or The 40% rule (aka Ellis Test) can be helpful to ensure your offering and the market aren’t diverging over time.

Who is responsible for assessing PMF?

Determining PMF is a team sport. It likely starts with and is spearheaded by Product Management and Product Marketing during discovery and development but will ultimately require support from User Research, Sales, Customer Success, and other groups in the organization.

Ongoing assessment of market fit will come through your Customer Sucess or Growth teams as they constantly monitor the performance of the product (NPS, Rule of 40%) and ultimately, your sales, sales-ops, and finance team looking at signals such as ARR growth, LTV (Lifetime Value) to CAC (Customer Acquisition Cost) ratio. Note – revenue or revenue-based derivatives may be good measures of PMF but it happens way too late in the product lifecycle to be use exclusively.

Conclusion

Shipping any product or even substantial features without validation during discovery and development is highly risky and will likely result in expsnive and disruptive pivots.

The PMF signals strengthen as you get closer to a released product, but you should still start as early as possible with customer/user sessions around concepts, ideas, and USPs because the costs of changing your focus and product plans increase substantially once you have released something to the market.

Product

Casual Coding with Claude (Part 1)