lark studio

    My journey in Jan '25 into building with AI did not begin with AI. It actually began with a handtyped HTML website, as I last did circa Geocities 1999. The original concept was simple: have a user answer some questions about their startup and get ChatGPT to generate a custom, acerbic response. Why? because everytime I put a bad idea into ChatGPT, it acted like I was the next Kevin Systrom.
    Pretty soon I came to a question about the form tag, which I plugged into the AI. Lo and behold, it generated a huge snippet of code in just a few seconds. After that moment, I leaned heavily on Code Copilot to help me build and deploy the site.
    One of my early discoveries was that ChatGPT needed context for the answers I was sending (i.e. the questions). This is obvious when you think about it, but the form tag is built for a human receiver and therefore doesn't do this automatically. What's more, the AI often needed some interpretation of those questions. For instance, 4/5 times it understood that by 'incubator' I meant 'a tech incubator.' But sometimes it would quip about chicken eggs. I wanted to ask another question about how many hours the user spent watching Y-Combinator vids on YouTube each week—the joke being that it's easier to consume content about startups than it is to actually build one. Unfortunately, ChatGPT didn't understand that watching-not-making was bad, and it would recommend the user watch more videos. In the end, to give full context for this question took more tokens than the payoff was worth. Moves like that changed the vibe from roast to potatoes, but, in the end, form matched function.
    I sent a working version to Jake, who recommended I add some style and, for fun, a tool tip. I grumbled to myself even as I knew he was right. A few hours later and not overthinking any of the AI-recommended style decisions, I landed on a professional-enough looking website.

Takeaways: There is no substitute for starting. Then, once you get it working, take the time to add a little pizazz.

• Month: January
• Tools: Code Copilot, OpenAI (platform), Gemini, Firebase, Sublime, Javascript, HTML, CSS
• Product: startupconsult.biz

    While I chewed on another web-based idea, I decided to try my hand at an iPhone app. That's one of the interesting things about AI codegen: you're not limited to programming only with the language, framework, or platform you know. By this point I had been introduced to Cursor and it was getting a lot of buzz, but I wanted to write in Xcode so I could take advantage of its preview features. Something was off in how Cursor and Xcode updated files to one another, so I ran both programs side-by-side and just pasted code between the two. If inelegant, it worked.
    My key learning came when Chris Winslett put out a memo at Innovation Depot about a Developers Show and Tell. I asked if I could come, even though I'm not a developer, and he kindly said Yes.
    Then, as soon as I set this deadline, I snagged on something, progress stalled, life interrupted the flow. A week passed with no work done and I had to decide: push or bail. The night before Dev Show and Tell, knowing that I was barely invited in the first place, I stayed up late choosing a clear parti for the app, reducing functionality to bare usefulness, and making sure it worked.
    At the meetup, I was the only non-engineer. Everyone else had years of experience and presented their work in the weeds. When it came my time to share, I plugged in my laptop, ran the simulator, and seemed to surprise everyone with a simple app that displayed quotes on the Lock Screen. I demonstrated how I wrote it and what I could get from Cursor with a simple command. We had a lively discussion about AI codegen.
    With the demo over and feeling unreasonably confident, I decided to shelve this project because there was (and is) much I wanted to learn outside the narrow purview of Apple, iPhone, and SwiftUI. To finish and launch meant going through the Apple store rigmarole, and I wasn't ready for that. Plus, my next app idea was already on deck.

Takeaway: There is no substitute for finishing, even if the project is not done-done.

• Month: February
• Tools: XCode, Cursor, SwiftUI
• Product: incomplete

    We all have an itch to build the Instagram killer, don't we? (don't we?) I started with these questions: could I recapture the community elements of OG Flickr and the pure fun of early Insta, and get people to pay for it? Beyond those ideas, there were really two big problems to solve here: one about the code and one about the business.
    To code first. I was now using Cursor exclusively, and having run through Harper's method with Claude Sonnet 3.7, I wondered if it was better to start from scratch or have the AI build a clone and then remove the parts I didn't want. Let me save you the time: building from scratch is the better approach. You're going to fight technical debt either way, but debugging is a whole lot easier when you know every component that's been built and can test your app bird by bird.
    As far as the business is concerned, there are a few mobile and web apps that seek to replace Instagram. None is a contender, none is even close. That should tell you what you need to know.
    After about ten hours of work, I launched on Firebase and asked Cary to join. He immediately had a sign up problem that was fixed when he restarted his browser. His problem, not mine, but still my problem, you know? I soon invited a few more friends who jumped in and started to post.
    For simplicity's sake, I had built the prototype without explicit following-follower relationships, meaning that all posts went to a single feed to which everyone was a contributor. From this decision emerged an interesting visual conversation that Jared called exquisite corpse. The app was functional and fun.
    Somewhere between the thirty- and forty-hour mark, I had a decision to make: push or bail? Facing the technical challenge of implementing a typical follow-feed system, given what I had observed about the business models of other Insta-clones, and considering the sunk cost of my time, this seemed to be a reasonable off-ramp. I don't like the term 'MVP' but I do like the alternative 'SLC': Simple, Lovable, Complete. For me, it checks all three. And naturally, I was already thinking about a new challenge.

Takeaways: Sometimes the other players in a market can save you a lot of time, effort, money, and social capital. Building an audience around a product is as important as the product itself.

• Months: March & April
• Tools: Cursor IDE, Claude, Firebase, Typescript, HTML, CSS
• Product: a celluloid finch

    This website is a blob, but reflection through writing has always been a valuable exercise for me.
    My big takeaway (as updated July '25): the more I make with AI codegen, the more I want to learn to code. I think it's a lot more fun to code and debug manually, use old-fashioned Google searches, dig through Stack Overflow snipes, and reuse code from previous projects; and then lean on Claude for flair. If you love problem solving, that's the right order of operations. And yet, progress in that mode would be so slow for me. So I continue to rely heavily, almost completely on AI. Except for the words, which are all mine.

• Month: April
• Tools: Sublime, HTML, CSS, Javascript, Google, Claude
• Product: you're looking at it

    The first product I validated in my startup journey was a photo printing business. That was in 2024, before AI codegen had become a major part of the development conversation. At that time, my big question was how to handle customer photo upload and storage with a UX that reflected the product. I tried Shopify and Wordpress and traded emails with people who built on those platforms, trying to explain what I wanted and how it differed from everything else out there. The idea that I would make a wireframe from which a developer I knew only via email would build a functional uploader and then we'd go back and forth hammering out the finest nuances of the UX was just impossible to imagine based on these exchanges. Their incentive was to build it fast and easy, and mine was to create a great user experience. As a business designer with a novel concept, I knew I needed to touch every aspect of the product directly. That was impossible with these third parties, and yet I had no way to program it myself. So I let it go.
    Fast forward a year, and, due to developments in AI, the landscape was completely different. So I decided to revisit this idea. It was immediately clear that I could build and deploy a site with all the necessary functionality in one day. Incredible, right? So, before I spent that day, I set out to solve the next set of problems: distribution, awareness, demand. And the problems I knew would accompany a consumer product: the bugs of business like email, customer service, and (in this case) being chained to a printer.
    Even with the ability to build the technical apparatus, I could not fit the pieces together in a way that made business-sense based on the time, trouble, and revenue I projected. So once again I let it go. Or, maybe I just put it back in the hopper. You'll see from the next project that things have a way of coming back around.

Takeaway: If you're gonna go to the trouble to start a business, make sure it’s one that suits your goals.

• Month: May
• Tools: Claude.ai, Claude Code
• Product: abandoned

    Revisiting my February SwiftUI project and preparing to launch....

• Month: June
• Tools: Claude Code, Xcode
• Product: coming soon

    For July, I planned to vacation from digital projects in order to knock out some long-standing home maintenance tasks. But as soon as I got started, I wondered if there was an app to help me make a maintenance schedule based on the exact systems in my home. I didn't find one, so why not build it?
    At first I thought this was just a prompt problem. How do I get the LLM to ask the right questions of the user in order to make a good schedule? Thus, my first solution was simple: write a prompt. Users could download it, run it through their LLM of choice, copy the results into a document editor, organize them as they see fit, and print. It was DIY, it fit the ethos.
    Once in it, I discovered that the full product is more of a format problem. Turning what the LLM outputs into something a human can easily use (printed document, spreadsheet, set of calendar events) takes some work. Could I automate that?
    Thus, my second idea was less simple: prompt the conversation on a website, have the LLM output the results as markdown, and convert that into a tidy document. The markdown part is pretty easy, but getting a clean, repeatable, dare-I-say-beautiful schedule from an AI without mistakes is a tall order. And that's to say nothing of costs and covering them. Meanwhile, you can get average results on your own without a great prompt.
    So, I returned to the first solution. If you're interested, a link to my prompt is below. I developed it with Claude but preferred the output of Gemini. It should work with any AI, and you'll probably need a paid account to complete it. After that, Pages is great for quick, clean formatting. Once laid out, I passed that file back through Gemini and had it produce a calendar file. Which was janky but quickly fixed with a single round of corrections.

Takeaway: Is it Simple, Lovable, Complete? Maybe. Is it DIY? Yes.

• Month: July
• Tools: Claude.ai, Gemini, Sublime Text, Pages
• Product: diy home maintenance schedule prompt