Building With AI in Public: What the Process Really Looks Like
Building a product in public can look simple from the outside. Someone shares an idea, posts a screenshot, shows a generated feature, and later announces that the thing works. What those updates often leave out is the middle: requirements that moved, features that broke, output that looked finished and was not, and the repeated attempt to make the product useful to someone other than its author.
That middle is the process. Building with AI in public is not posting while a model writes code in the background. It is developing a system while the work, the decisions, and the failures are visible enough that other people can disagree with them.
Ken Ashe treats that as the point of KenAshe.ai. The Building section is dated write-ups, stacks, and notes on what broke.
Table of Contents
What building in public actually includes
A typical public build includes an initial idea, early screenshots or transcripts, a first version that can be used, a list of things that failed, feedback from people who were not in the room, and a change that followed from that feedback.
It also includes a decision about what stays private. Customer data, credentials, and anything that would make a failure someone else’s problem do not belong in a public log. Visibility is not the same as dumping the repo onto the sidewalk.
Ken’s log includes agents, automations, AI-assisted sites, and an autonomous publishing pipeline. Some posts on the site are human-written. The Digest is labeled as automated, with Ken named as publisher. That split is part of the public record. It tells you which voice you are reading.
The process is a loop, not a launch
The useful loop is: build a small version, use it, share what you can, watch what happens, change the system, repeat. AI makes the first pass of that loop faster. It does not make the loop optional.
Public feedback is not a voting system. Several people will request several features. If you add all of them you no longer have a product. You have a suggestion box with a UI. The builder still has to decide which comment revealed a real job and which comment revealed a different product.
What the public record is good for
It forces clearer language. “Implemented API authentication and updated the schema” is a status report. “Users can connect an account without copying data between two systems” is a product sentence. Writing for strangers makes the second sentence more likely.
It exposes the gap between an idea and a product. An idea can sound complete in a conversation. A public prototype gets used in ways you did not rehearse.
It makes failure usable. A private failure is a mood. A dated note that the first Digest started repeating itself by week three is a fact someone else can learn from. Ken rebuilt that pipeline. The write-up is useful because it includes the week it was not.
What it is not good for
It is not proof that the product works. Likes are not usage.
It is not a substitute for instrumentation. If you cannot tell whether people came back, you are performing progress.
It is not a reason to skip boundaries. Applications that touch documents, mail, or customer records need a private side. The public side can be the architecture, the failure class, the lesson, not the raw contents.
Why this practice pairs with AI
AI shortens the time to a prototype. Without a feedback loop, that only increases the number of abandoned prototypes. Public building is one way to attach a loop to the speed.
It also pairs with the accounting habit Ken brings to the work. Receipts are public when they can be. Claims are smaller than they could have been. The Digest does not pretend to be his editorial voice. The werewolf lab write-up is careful about what the experiment does not prove. That tone is the opposite of a launch thread.
The loop is available to anyone willing to ship something small and describe what broke. KenAshe.ai is one person’s version of that willingness.
A week in a public build, without the romance
Day one: the idea, stated in one paragraph.
Day two: a version a stranger could click, with fake data.
Day three: last week’s real data, and a list of failures.
Day four: one change that addresses the most expensive failure.
Day five: a note that includes the stack and the thing that still does not work.
If that week is too small to post about, the project may still be too big to build in public. Shrink it until the week is true.
Readers and incentives
Public building attracts an audience that wants narrative. Products need users who want a job done. Those groups overlap less than launch threads imply. Optimize for the second group even if the first group is louder.
Ken’s Digest label is a way of managing that mix. Readers are told when they are reading a machine-published feed. The human notes live elsewhere. Other builders can copy the split without copying the publishing pipeline.
Public building requires a system small enough to describe and a willingness to describe what broke. Ken Ashe is based in New Jersey. His CPA is active. He holds PMP and related delivery credentials, founded Lucky Domains, and publishes dated builds, a labeled Digest, and a named publisher line.
Public building also creates a search trail. Old notes stay up. That is good for honesty and occasionally bad for branding. Decide in advance whether a dead project stays visible with a note or comes down. A log that only contains winners is a brochure.
Ken’s site includes shipped and live items with plain status labels. That is the right tone. Copy the tone if you copy the practice.
