TetraMesa

AI Build Copilot, Part 4: Preparing for Production

By

Part 3 was about building durably, so what happens after that? A successful prototype creates a new problem if you actually put it into some form of production. Not too long ago, if we built what we called prototypes, maybe they went to user testing, or we ‘sort of’ put them out there. But now? A lot of so-called tests really aren’t. That is, they’re really more actual rollouts. Just maybe not necessarily with the same rigor we used to give product launches. The line between that which was intended as prototype testing and so-called Minimum Viable Product (MVP) seems like it might get blurry.

The next challenge with launching a kind of prototype, but that which is maybe real product is someone may decide to use it. So… Is it really a prototype? Meaning… is this just some brochureware for testing or is there actual sign-up functionality, any kind of real billing, private information collection, and so on.

This is when the low-stakes experiment begins accumulating customers, private information, billing relationships, operational dependencies, and consequences. You have to make your own call on this kind of thing. I have to tell you, personally I’ve never loved the “false front door” thing for testing. I get that it can be useful, but sometimes it’s on the edge of unethical in how it seems to trick people. If your prototype is really a test and that’s understood, great. If the truth is it’s not much of a test, but a rollout? Then there’s probably some more risk elements and due diligence that should be covered.

Prototypes have a way of becoming products. Temporary credentials become permanent. Test data becomes customer data. A one-time API connection becomes a critical service. The final part of an AI-assisted build is not clicking Deploy.

It’s deciding whether the thing can be operated safely. One thing that I’ve done along the way when building is created something I’ve called “Launch Blockers.” This is different than a UI backlog or minor changes you find along the way. It’s things like purging schemas, or making sure live production feature flags are set properly. It means a real security review. Things like that.

[Read more…]

AI Build Copilot, Part 3: Building a Durable Workflow

By

In Part 2, we went over Staying in Control of your build session. Now it’s time to start looking at consistency and reliability issues. AI conversations are useful working spaces. However, they’re not reliable long-term project memory. Sessions end. Context fills up and you have to switch chats. Maybe you switch models from Fable 5 to GreekTragedy-7.6 or ElonsNextWife-10.4. Files are edited elsewhere, etc.

An agent’s understanding of the project can become stale while sounding completely confident. That’s why the project must survive the chat and there’s ways to do that.

[Read more…]

AI Build Copilot, Part 2: Staying in Control

By

We started in Part 1 with what the bright shiny What AI (Site builder) Demonstrations Leave out… and it was fairly high level. Now we’re going to dive a bit deeper and yes, somewhat into some technical things. My goal remains: to help level up those in generally more non-technical roles, especially product management. (Though of course, what that technical continuum looks like varies widely.) Let’s start with some basics, and drill down from there…

The dangerous thing about AI coding assistants is that they are often very good.

Huh? How could that be dangerous? It’s dangerous because if they were obviously terrible in spots, we would remain more alert as we used them. Instead, they’re helpful enough to earn trust and inconsistent enough for us to experience times where we clearly shouldn’t have trusted them.

The interaction feels conversational. The agent explains what it is doing, uses reassuring language, and often anticipates the next task. Over time, it becomes easy to stop evaluating each recommendation independently.

That’s the lull.

The assistant is called a copilot for a reason. Do not become its passive passenger.

Disclosure: I did use AI in this series for spelling, grammar and to fill out a few bullet lists with minor items I missed. Generally, I draft, do outlines, and write everything; then have AI check spelling, grammar, and completeness; maybe clean up a few items. Here I did miss some bullets though and those are filled in. Where that was true, I checked sources on ‘truthiness’ for everything. The point is, every high-level thing I go into here are things I’ve personally run into – recently – while working on real projects. So it may seem like a lot, but none of it’s fluff. And you ignore them at some degree of risk.

[Read more…]

AI Build Copilot, Part 1: What Demos Leave Out

By

I’d recently put up an article about a joke site I build for fun while helping create some overall scaffolding for a more serious project. At the outset, I’d pointed out part of my motivation for writing about some of these things is to try to offer some tips and mention some of the traps that go with the reality of using these tools as product people. The bubbly happy path posts and videos seem to mostly gloss over some of the real speed bumps and risks along the way. I get that demos are often to help people just see what’s possible. But lately there’s such a hard sell to some of these things, and so full of clickbait as to often be somewhat disingenuous.

As “non developers” use these tools more, it’s obvious enough that AI coding tools can be astonishingly productive. They can also be confusing, unreliable, expensive, overconfident, and occasionally dangerous. As product people at all levels from Individual Contributor to Senior Managers, VPs, etc., start getting deeper into these things, (not as full developers, but just as useful parts of our new toolkits), we’ll need to get real about some basics. The Happy Path feel good posts on LinkedIn and demos on LinkedIn rarely go over the many real blockers.

So I’m going to do some of that here, in several parts.

[Read more…]

I Built a Joke Site with AI – Then It Became a Production System

By

This started as a joke that got out of control, but the build produced a few lessons worth sharing.

Most of my work is product-focused rather than production-focused. Product and marketing people should spend their time with customers, markets, competitors, business models, and worthwhile problems. Becoming absorbed in production can turn attention inward instead of outward.

Still, sometimes you need or just want to build something yourself. Like everyone else, I now use AI for all manner of things. But there’s a difference between a throwaway prototype for quick user testing and something that might approach production. For one project, I had to move beyond simple prototypes and build a modern AI-assisted production pipeline without experimenting on a client’s product, a company’s core offering, or anything containing important customer data. So I needed something harmless, but sort of real, to test with. To borrow from my woodworking hobby, I practice new techniques on cheap material before touching fine red oak. The same principle applies here: make early mistakes where failure costs essentially nothing.

So I built a joke website, but the tools and methods behind it are no joke. They are genuinely powerful. At the same time, the more serious project benefits from using this as a no risk practice platform. So here’s where we come out:

  • This article: I’ll just tell you what I built and some of the tools I used to do it.
  • Next Up: A series on AI Build Copiloting in general for “semi” technical users. That is, product folks with some basic engineering familiarity, who need to dive a bit deeper into these areas, even if only part of the time.
  • After that: Another series focused on building in databases with AI assistance.
[Read more…]

Of Oracles & RWA Headwinds

By

Tokenization of Real World Assets (RWA) is on a tear, but will some aspects be held back from mass market adoption for lack of trusted information about certain types of assets? Today’s Oracles, (that supply external, off-chain information to a blockchain or smart contracts), don’t seem ready for richer types of information that we’ll need. Today’s oracle infrastructure is better suited to selected structured data points than to richer, messy reporting packages such as engineering reports, appraisals, legal exceptions, maintenance issues, lease details, or materiality judgments.

Mckinsey estimates tokenization markets worth somewhere from $2T – $4T by 2030. They aptly point out, “Tokenization’s rate and timing of adoption will vary across asset classes” and “Given their characteristics, certain asset classes will likely be faster to reach meaningful adoption.” In other words, easier things will happen faster. Obvious enough. Others assessing future tokenization markets show more of the usual charts with curves bending quickly upwards. The more challenging areas though, will be where they’ve always been challenging in terms of regulatory issues, information flows and so on. When we get into “REAL” real world assets is where things are harder. That is, things like gold, mutual funds, or others that are already virtualized really, should translate more easily to representative onchain tokens than messier deals such as a local shopping center development, a piece of art, or similar. Let’s say a token says you own part of a building. But what if that asset has a problem? Who reports it? Where does the report live? Who’s liable if nobody updates investors?

Traditional finance has longstanding reporting structures. And they still get things wrong sometimes or suffer from fraudulent claims. When we build an abstraction layer like a blockchain on top, we need ways to bridge a reporting gap. Successful adoption here isn’t going to be about just splitting things into smaller pieces with tokens. It’s time to look at why and suggest some solutions.

The idea for this post came out of a LinkedIn thread where Igor Samotesov talked about why trillions aren’t flowing quickly into onchain RWA instruments. And I just happen to be re-reading a book on taxonomies. So this is the result. Here are some more potential reasons for what’s going on and possible solutions.

[Read more…]

Using Skills for AI Builds: Product Safety

By

Note: This isn’t about general skill in building things with AI… it’s specifically about things called Skill files or their similar counterparts.

Are you a product person at any level who is either building yourself or managing others that are increasingly doing some direct building?

Like a lot of us, I’ve been making some of my own stuff with AI tools. Or in some cases experimenting to understand their use cases better. Among the hype cycle things of this year are Skill files. (Or more generally skill type instructions for AI tools.) There’s whole marketplaces for them. This post is just a warning I’m throwing out there as a caution along with some ideas for mitigating risk. It’s not meant to be overly alarmist, but the “You can use skills to do anything!” hype is so overwhelmingly thick sometimes, it just needs some balance. And actually, I think it’s not just clickbait, it sometimes feels irresponsible and dangerous.

[Read more…]

Web3 Consumer Protection: Progress, Gaps, and What You Can Do

By

Consumer protection in Web3 has come a long way, but it’s still nowhere near what you’d get from a traditional bank or broker. Billions in losses from hacks, rug pulls, and failed platforms tell a story that headlines alone can’t fully capture.

Some frameworks are in place now, and more are taking shape. But the gaps are significant, and they affect you directly.

This post breaks down what protections actually exist in Web3 today, where they fall short, and what you can do to protect yourself while the rules keep catching up.

This article is mostly for ordinary users and investors trying to understand what protections they actually have before using exchanges, wallets, tokens, or DeFi protocols. However, it’s also useful for those building in Web3, because these unresolved protection gaps are the kinds of issues that shape user trust, investor confidence, and adoption decisions.

[Read more…]

Why the Best Web3 Products Feel Less Like Crypto

By

For too long, the crypto space has been obsessed with selling the “engine” of the blockchain. Whitepapers of new projects focused on technical features and used a special jargon (e.g. words like “gwei” “slippage” and “hash”). It was like showing users the gears, the grease, and the technical specifications of a new car model, and then wondering why the general public wasn’t buying it.

It finally seems that in 2026, maybe this attitude is giving way to better product sense. Successful Web3 products are starting to make the technology invisible. Or at least trying. They have finally realized that users don’t care about features for their own sake, but instead about the benefit they get.

The era of “crypto-first” because it’s some self-sovereign anti-establishement thing that’s good for you is dead. The era of “stealth Web3” has begun. Here are some guiding principles for this new era.

[Read more…]

What “Decentralized” Really Means in Web3 Products

By

The early days of the internet were characterized by a dream that was like a philosophical stance; a “World Wide Web” with no owners that could be used by anyone. (Though infrastructure and control points still existed.) Over time, that dream turned to become a much more commercialized Web, with major portions consolidated in the hands of a few tech giants like Amazon, Google, and Facebook. Web3 was in some ways meant as a “reboot” of that original dream. A reboot powered by a single word, loaded with diverse meanings: “Decentralization”.

However, as the term has moved from whitepapers to marketing billboards, its meaning has become a bit blurred. Much of the time, decentralization is used to refer to technical aspects of elements referred to as crypto or Web3. On the general user side, many may believe that if a product involves a “token” or a “wallet” it is decentralized. This is a potentially inaccurate perception. In reality, decentralization is more like a spectrum than a binary setting. The question isn’t if an app is decentralized, but how much. And the core of such things may be technology based, but there’s other aspects that should be considered.

This post sketches a four-aspect map of decentralization that you can use to look past the branding into the actual way a product functions.

[Read more…]

Location

We're located in Stamford, CT, "The City that Works." Most of our in person engagement Clients are located in the metro NYC area in either New York City, Westchester or Fairfield Counties, as well as Los Angeles and San Francisco. We do off site work for a variety of Clients as well.

Have a Project?

If you have a project you would like to discuss, just get in touch via our Contact Form.

Connect

As a small consultancy, we spend more time with our Clients' social media than our own. If you would like to keep up with us the rare times we have something important enough to say via social media, feel free to follow our accounts.