About six months ago, I built a museum explorer app for kids called MuseKat, which catapulted me into a new and unexpected phase of life: An App Developer.

Ever since, my social feeds have been overwhelmingly flooded with hype cycle chatter for AI builders today that goes a little bit like this:

"There's never been a better time to build a business..."

"If you're not making $40k MRR by month three of your AI startup, you're doing it wrong..."

"Here's the exact playbook you need to launch a successful AI startup..."

It's a lot of FOMO, but one thing is clear: You need to build it first.

The only question is, what happens next?

Since I'd never really built software before, I started off in a pretty perilous and meandering part of the builder journey. Yes, I successfully shipped something on the Internet, but I didn't know how to give it polish.

While I did run user tests with early users (even with the pretty half-baked web app version of the thing), the expectation from my target audience (ie: parents of young kids) was that I needed a native mobile app to drive real adoption. But that's where I hit a snag: My no-code technical capabilities tapped out at mobile.

Luckily, I was able to find someone who rearchitected the app for me, in a much cleaner, mobile-first construct. We moved from Flask to React, streamlined user authentication, and gave the technical architecture an actual strategy.

But it took way too long. And, most important, I got locked out of technically in a way that made me afraid to make iterations or feature changes to the product, without completely knocking things offline again. So then the iterating and building kind of just...stopped. This was really not good.

What I noticed was, the urge to keep building stuff did not disappear, I ended up just applying that skill in other contexts: I built internal tools. I built super weird side projects. Then I built a new business about building stuff. (Meta, I know. But this one at least pays me...)

I realized that while my idea for MuseKat the museum explorer may still be good, it wasn’t the idea that stalled me—it was the process of building itself. And I needed a different approach.

This time, I tried something different: Build fast. Stay in control. Let kids teach me what to do next.

One of the biggest things to come out of my first six months of working on MuseKat was less about the end users who wanted to bring their kids to museums with Miko the Meerkat. It was about the meta-cognitive layer of learning about building AI tools while working in partnership with kids in classrooms.

Coupled with very consistent feedback I've been hearing from parents about existential dread about AI in general, and fears of too much screen-time in their families, it got me wondering:

So, I wrote up a quick concept brief about what this could look like, and mapped out a few digitally enabled app experiences that could essentially support AI literacy fundamentals for young kids. I got this brief in front of some education leaders and somehow landed a pilot partner in less than a week.

I thought that was pretty interesting. I'd been pushing on museums and parents and microschools for months about how they might incorporate the MuseKat museum learning lens into their strategies and coming up empty. So to land a month-long pilot on short notice felt like nothing short of a miracle.

I decided to lean into this unique opportunity as a way to short-cycle a PMF cycle. Here's what happened next:

What I've learned is:

1. Schools want to teach AI fluency more than parents are comfortable with it today

2. Parents are even more afraid of AI than I thought initially (my most tech-forward friends were among the least likely to want to introduce any games like this to their kids)

3. Kids love playing games where they can take photos

The best part is that I only burned a week to figure this out. Onto the next.

This year, I've been learning at a level that's pretty unprecedented (even for me). Not only have I set out to start a business this year, but I've been slowly (and painfully) teaching myself how to build software without coding.

1- Perfect the process, not the prototype.
Like a lot of things, I think the first cycle through anything new is slow and painful and burns way more energy than it should. But the nice thing was, even with this second concept, I did in a week what took me two months earlier this year. This goes to show what I should have known all along but obviously had to learn the hard way: You just need to get your reps in.

2- Don't lose control over your code.
I've had a lot of anxiety about calling myself a developer this year because things break all the time, and I am wholly unequipped to fix them on my own. You'd be surprised with how many creative solutions I've had to resort to in order to regain technical agency or debug an error. But the biggest problem was handing things off for too long. In the next cycle of building, I need to find a way to stay closer to the product, even in moments where I might need a little help getting it polished.

3- Learn something new every week. Build something new every week.
If I spend a week working in AI where I fail to move the needle forward on my own technical development, then I'm falling behind. That's why I commit to learning something new by building something new every week. (Last week was fully functional app prototypes with Replit, this week is MCP, in case you're wondering...) Oh and by the way: Do not invest money in any buildout for more than 2 weeks unless you are really sure that it's what people want.

By the way, my favorite way hack to learn something new is to build something new first. This is why I'm teaching people how to build things through my new AI training and workshop business, Build First Academy.

This summer, you can sign up to learn how to build with me at in AI Summer School from August 11 - 15, 2025 at https://buildfirst.ai/summer-school. We'll go through a version of this five-day build cycle that anyone can follow.

About six months ago, I built a museum explorer app for kids called MuseKat, which catapulted me into a new and unexpected phase of life: An App Developer.

Ever since, my social feeds have been overwhelmingly flooded with hype cycle chatter for AI builders today that goes a little bit like this:

"There's never been a better time to build a business..."

"If you're not making $40k MRR by month three of your AI startup, you're doing it wrong..."

"Here's the exact playbook you need to launch a successful AI startup..."

It's a lot of FOMO, but one thing is clear: You need to build it first.

The only question is, what happens next?

Since I'd never really built software before, I started off in a pretty perilous and meandering part of the builder journey. Yes, I successfully shipped something on the Internet, but I didn't know how to give it polish.

While I did run user tests with early users (even with the pretty half-baked web app version of the thing), the expectation from my target audience (ie: parents of young kids) was that I needed a native mobile app to drive real adoption. But that's where I hit a snag: My no-code technical capabilities tapped out at mobile.

Luckily, I was able to find someone who rearchitected the app for me, in a much cleaner, mobile-first construct. We moved from Flask to React, streamlined user authentication, and gave the technical architecture an actual strategy.

But it took way too long. And, most important, I got locked out of technically in a way that made me afraid to make iterations or feature changes to the product, without completely knocking things offline again. So then the iterating and building kind of just...stopped. This was really not good.

What I noticed was, the urge to keep building stuff did not disappear, I ended up just applying that skill in other contexts: I built internal tools. I built super weird side projects. Then I built a new business about building stuff. (Meta, I know. But this one at least pays me...)

I realized that while my idea for MuseKat the museum explorer may still be good, it wasn’t the idea that stalled me—it was the process of building itself. And I needed a different approach.

This time, I tried something different: Build fast. Stay in control. Let kids teach me what to do next.

One of the biggest things to come out of my first six months of working on MuseKat was less about the end users who wanted to bring their kids to museums with Miko the Meerkat. It was about the meta-cognitive layer of learning about building AI tools while working in partnership with kids in classrooms.

Coupled with very consistent feedback I've been hearing from parents about existential dread about AI in general, and fears of too much screen-time in their families, it got me wondering:

So, I wrote up a quick concept brief about what this could look like, and mapped out a few digitally enabled app experiences that could essentially support AI literacy fundamentals for young kids. I got this brief in front of some education leaders and somehow landed a pilot partner in less than a week.

I thought that was pretty interesting. I'd been pushing on museums and parents and microschools for months about how they might incorporate the MuseKat museum learning lens into their strategies and coming up empty. So to land a month-long pilot on short notice felt like nothing short of a miracle.

I decided to lean into this unique opportunity as a way to short-cycle a PMF cycle. Here's what happened next:

What I've learned is:

1. Schools want to teach AI fluency more than parents are comfortable with it today

2. Parents are even more afraid of AI than I thought initially (my most tech-forward friends were among the least likely to want to introduce any games like this to their kids)

3. Kids love playing games where they can take photos

The best part is that I only burned a week to figure this out. Onto the next.

This year, I've been learning at a level that's pretty unprecedented (even for me). Not only have I set out to start a business this year, but I've been slowly (and painfully) teaching myself how to build software without coding.

1- Perfect the process, not the prototype.
Like a lot of things, I think the first cycle through anything new is slow and painful and burns way more energy than it should. But the nice thing was, even with this second concept, I did in a week what took me two months earlier this year. This goes to show what I should have known all along but obviously had to learn the hard way: You just need to get your reps in.

2- Don't lose control over your code.
I've had a lot of anxiety about calling myself a developer this year because things break all the time, and I am wholly unequipped to fix them on my own. You'd be surprised with how many creative solutions I've had to resort to in order to regain technical agency or debug an error. But the biggest problem was handing things off for too long. In the next cycle of building, I need to find a way to stay closer to the product, even in moments where I might need a little help getting it polished.

3- Learn something new every week. Build something new every week.
If I spend a week working in AI where I fail to move the needle forward on my own technical development, then I'm falling behind. That's why I commit to learning something new by building something new every week. (Last week was fully functional app prototypes with Replit, this week is MCP, in case you're wondering...) Oh and by the way: Do not invest money in any buildout for more than 2 weeks unless you are really sure that it's what people want.

By the way, my favorite way hack to learn something new is to build something new first. This is why I'm teaching people how to build things through my new AI training and workshop business, Build First Academy.

This summer, you can sign up to learn how to build with me at in AI Summer School from August 11 - 15, 2025 at https://buildfirst.ai/summer-school. We'll go through a version of this five-day build cycle that anyone can follow.