Most organizations have already tried AI. They’ve drafted emails with ChatGPT, built slides with Claude, and maybe run a pilot or two. Many of those pilots quietly stalled. In this episode of the Snowpal Podcast, Krish talks with Trehan Stenton, who helps multi-location and growing businesses turn strategy into process and then uses AI and change management to make those changes stick. His main argument: when AI implementations fail, the tool is rarely the cause. The usual causes are unclear processes, messy data, missing governance, and people who were never told why the change is happening.

AI + Snowpal API: Reduce Time to Market

Podcast

The Human Side of AI: Leading Change That Lasts — on Apple and Spotify.

1. Why pilots fail

Trehan cites research estimating that about 95% of AI pilots fail. In his experience, the causes are consistent:

• The expected results are unrealistic. Leadership treats AI as a fix for the whole organization, but it can’t be one.

• The rollout moves faster than people can absorb it. An excited CEO pushes AI down the org chart, and middle managers are left unsure how to apply it.

• The tools sit on broken processes. If the process underneath is incomplete, the data is dirty, or information is spread across systems, the model gives wrong answers. Automating a mess makes the mess bigger.

• People stop trusting it. One bad answer (”I tried Claude and it was completely wrong”) turns into resistance to every AI tool that comes after.

His key distinction is that using AI as a personal assistant and using it inside business workflows are different disciplines. Writing emails and slides needs no governance. Automating workflows and deploying agents need defined requirements, success metrics, exception handling, and a governance model.

2. Case study: two AI rollouts in dentistry

Trehan has a healthcare background and offers two examples from dental practices. They show that the same kind of technology can fail or succeed depending on how it’s introduced.

AI radiography: what went wrong, then what fixed it

AI-assisted radiograph analysis marks likely decay, recession, and cracks on the image, which helps both the clinician and the patient see the problem. The first rollout struggled:

• Clinicians weren’t told how the model reaches its conclusions, so they didn’t trust it.

• Nobody explained that the system has to be trained with feedback, the same way a new dental assistant isn’t fully capable on day one.

• Distrust of this one tool spread into resistance to AI tools in general.

The fix was mostly about positioning. The tool was reintroduced as a “second opinion.” The clinician is still the primary decision-maker, and the AI adds another view. After that change, adoption picked up quickly.

Ambient transcription: success from the first day

Ambient AI scribes record the clinical conversation (in a HIPAA-compliant way) and draft notes and treatment outcomes. This rollout worked from the start because it:

• Started small with one group of users, the hygienists.

• Delivered an obvious benefit right away: about 10 minutes saved per hour on writing notes.

• Kept a human reviewing the output. Hygienists checked the notes before they went into the system.

• Posed a low threat to clinicians’ professional identity. It took over a chore and left their judgment alone.

Pattern to reuse: choose first use cases that are high-benefit, low-risk, and low ego-impact. They produce people who will advocate for the next rollout.

3. Process first: a framework for implementation

Trehan jokes that his advice is always “boring,” but the order of steps matters:

1. Start with why. Leadership states the direction and the reasons behind it, so the team understands the change instead of seeing it as a threat.

2. Set priorities. Decide what the effort is for: efficiency, revenue, or customer experience.

3. Map the core processes. Document how work actually gets done today, including where the bottlenecks are.

4. Redesign the processes, don’t just speed them up. She cites research finding that only about 35% of organizations implementing AI actually redesign the underlying process. The rest try to make a five-year-old workflow run faster.

5. Clean the data and plan for exceptions. Models are only as good as the data and edge-case handling underneath them.

6. Apply tools to specific areas, at specific times, for specific outputs. Avoid broad multi-department transformations.

7. Define failure along with success. Run a time-boxed trial (for example, three months) with clear kill criteria, so a failing initiative gets shut down and replaced instead of lingering.

8. Build on small wins. Each quick win makes people more willing to accept the next change.

4. Governance and the cost of letting everyone experiment

Without governance, broad access to AI burns budget without producing results. Trehan mentions a report that Uber employees used about three months’ worth of tokens in one week after the company opened generative AI to everyone, with little to show for it.

Governance also covers accountability. Directors and boards are still responsible for decisions made in the business, whether a person or a model produced them. Trehan points to the case where an airline argued that its customer-service chatbot was effectively a separate entity. The court disagreed: the bot belongs to the company, so its decisions are the company’s responsibility. In legal and regulated settings especially, “the model told me” is not an audit trail.

Questions every AI program should be able to answer:

• Is the organization aligned on direction and priorities?

• Does the governance model keep up with how fast decisions are now being made?

• Where does risk sit in each automated process, and who owns it?

• What is the budget for tokens and compute, and how is usage monitored?

5. The real cost of an AI-assisted role

Krish raises a practical question that many startups now face. The cost of getting work done is no longer just salary:

Total cost of output = Human cost + AI cost (tokens, models, tooling)

Take two extremes for an engineering role:

Trehan’s answer: it depends on the process, but he would pay more for someone with a curious, questioning mind. His reasoning is that cheap labor producing AI output still needs an expensive person to validate it. When she builds agents for a manufacturing client, she wants a strong analyst who can question the numbers, understand what they mean for the business, and make recommendations, not someone who just generates answers.

The cost that gets overlooked is validation. If nobody on the team can tell whether an output is correct, the AI spend is wasted.

6. Discernment: knowing when to stop thinking and when not to

The word that comes up most in the conversation is discernment. AI can get a task about 90% of the way done. The remaining 10%, which includes judgment, reasoning, and context, is where people add value. Because AI speeds up decisions, organizations have to deliberately protect time for that judgment.

Krish describes the tension from an engineer’s point of view:

• When to delegate: if Claude or Cursor can do the work, he lets it, then reviews, adjusts, and merges.

• When not to: sometimes delegating made him slower on problems he has solved many times before, because the tool “sent him on a wild goose chase.”

Both hosts gave examples of AI not saving time. Trehan gave up on having AI build a presentation slide and made it himself in PowerPoint. Snowpal set aside two four-hour sessions to generate course images with ChatGPT instead of Canva, and after all the back-and-forth it took the same time. The images may have been better, but no time was saved.

Krish compares this to mental math. Calculators exist, but when he sets a stop-loss on a day trade, working out 1.6% in his head is faster than reaching for a tool. If you hand off every skill you have, you stop being different from anyone else using the same tools.

Trehan takes this further: value is shifting from IQ to EQ. That means noticing when a P&L looks wrong before running it through a model, sensing problems inside an organization, and explaining a vision clearly. These are the soft skills that make good leaders, and they are becoming more valuable as everyone else focuses on hard outputs.

7. What this means for software engineers

Asked how developers should adapt, Krish, who has built software for over 20 years, makes several points:

• The pace of change is what’s new. Software has always changed; now it changes much faster. What worked a month ago may not work today.

• Programming languages matter less. Snowpal has always used several languages and stacks. With current tools, the specific language or framework matters much less than knowing how to approach and architect an engineering problem so it scales and lasts.

• Consistency is the new hard problem. Checking that generated code works is fairly easy. You can even test it with other code-generation tools. Keeping code from several AI tools consistent with the rest of the codebase is harder. Without that discipline, the result looks like a thousand developers each contributing in their own style.

• Engineers still own production. When something breaks, AI will help find the bug, but the engineer needs to understand the codebase and how it grew: which tools generated which parts, how contributions were made, and how deployments run.

• Structural decisions still need people. Monorepo or polyrepo, how the team is organized, how contributions and deployments flow: these are still engineering leadership decisions.

• Being comfortable with constant change is a core skill. Expect something to be significantly different every week.

Trehan adds that specialists increasingly need to work like generalists. They should understand the upstream and downstream effects of a change, how it affects the customer journey, and how it connects to other parts of the business.

8. The consultant’s changing role

Both the client and the consultant now have access to ChatGPT, Claude, and Cursor. So why hire outside help? Trehan’s answer:

• Time and follow-through. Clients often have ideas but not the bandwidth to finish them while running the business. Consultants commit to timelines, measurement, and outcomes.

• An outside view. Clients tend to think about processes in terms of how they’ve always done them. Consultants bring patterns from across the industry.

• Transparency. Be open about when and how AI is used to produce deliverables.

• Teaching the client. Build the methodology into the client’s team, such as documenting processes and finding bottlenecks, so they can keep going on their own.

• Pricing on outcomes instead of hours. Tie fees to efficiency gains, revenue, or acquisitions delivered, rather than billable hours or documents.

9. Workforce and global perspective

On jobs, the conversation is candid. Trehan notes that many corporate layoffs are driven by share price as much as by AI. Still, as a small-business operator she now asks “hire or automate?” and has found that growing the business 4x no longer means growing headcount 4x. Back-office work such as accounting is an obvious target for automation. Commoditized offshore work is at real risk, and some of that capacity may move toward quality assurance.

His view is that AI is revolutionary in what it can do but will be evolutionary in how it rolls out, similar to the printing press or the early internet, when “SeniorNet” classes taught people how to get online. Adoption will be uneven, even within a single neighborhood.

On global competition, she describes New Zealand’s “number 8 wire” mindset: the idea that you can fix anything with basic fencing wire and ingenuity. Smaller countries and companies can iterate faster in niche markets (Xero is a New Zealand example). AI helps level the field further because meaningful products no longer need large teams.

Key takeaways

1. Fix the process before adding AI. Automating a broken workflow makes it worse.

2. Start small, choose low-ego use cases, and show value quickly. Ambient transcription succeeded where radiography first struggled.

3. Position AI as a second opinion, and explain how it works and how it learns.

4. Define failure and set kill criteria up front.

5. Govern token usage and accountability. The organization owns its bots’ decisions.

6. Budget for validation. Total cost = people + tokens + review.

7. Protect discernment. Delegate what the tool does well and keep the skills that set you apart.

8. For engineers: architecture, consistency across the codebase, and comfort with constant change matter more than any single language.

As Trehan put it at the end: “We’re only limited by the questions that we can ask.”

Statistics mentioned in the episode (95% pilot failure rate, 35% process redesign, 65% wage premium for AI roles, the Uber token figure) are as cited by the guest and have not been independently verified here.

AI + Snowpal API: Reduce Time to Market

To make the numbers concrete, the examples use a hypothetical young U.S. couple with one child. They are rough planning estimates, not universal averages. Costs vary widely by location, income, and lifestyle, and several categories overlap, so the figures should not simply be added together.

Introduction

Personal finance rarely fails because of one catastrophic decision; it erodes through a compounding system of depreciation, financing costs, behavioral friction, recurring expenses, and lost investment returns. A car upgrade, deferred-interest purchase, oversized shopping trip, or daily convenience may appear manageable in isolation, but collectively these choices can redirect tens of thousands of dollars away from emergency reserves, debt reduction, homeownership, education, and long-term wealth. For a young couple raising a child, understanding this system is especially important: every dollar spent carries both an immediate price and an opportunity cost—the future value it could have created elsewhere. The fifteen categories that follow quantify these hidden tradeoffs and show how greater visibility, intentional limits, and better allocation decisions can convert ordinary spending into lasting financial security.

1. A Car Is a Depreciating Asset—and the Bling Dies Quickly

A car starts losing value the moment it leaves the lot, and the fastest way to accelerate that loss is chasing the version with more bling: the bigger trim, the newer model year, or the upgrade that felt necessary at the dealership but stops mattering within a month.

The type of car matters less than the pattern around it—how often it gets upgraded, how many optional packages get added, and how much of the purchase gets financed. A modest, reliable car kept for eight to ten years will almost always beat a nicer one traded in every three, even though the second option feels more successful in the moment.

The payment is only part of the bill. AAA estimates that the average new vehicle costs about $1,072 per month to own and operate when depreciation, financing, fuel, insurance, maintenance, and fees are included. A family with two newer vehicles could easily devote $1,500 to $2,100 per month to transportation.

**Potential savings:** Keeping reliable cars longer, avoiding unnecessary upgrades, and replacing only one vehicle at a time could preserve roughly $400 to $800 per month, or $4,800 to $9,600 per year. The real luxury is not a prestigious badge; it is dependable transportation without a crushing payment.

2. Interest-Free Loans on Random Purchases

“Interest-free” financing on furniture, electronics, phones, appliances, or exercise equipment sounds like a gift. Even when the interest rate is genuinely zero, however, the purchase still commits future income.

A family could easily accumulate the following payments:

- Furniture: $125 per month

- Two phones: $80 per month

- Exercise equipment: $75 per month

- Electronics: $70 per month

That is $350 per month, or $4,200 a year, assigned to things purchased months ago. It is also $350 that cannot go toward an emergency fund, retirement account, vacation, or education savings.

Zero-percent financing is safest when the purchase was already planned and the money needed to pay for it already exists. Otherwise, it can make an unaffordable purchase appear affordable simply by shifting attention from the total price to the monthly payment.

3. Deferred-Interest Credit Cards

Deferred interest is more dangerous than a conventional zero-percent offer. If the balance is not fully paid by the promotional deadline, interest may be charged retroactively from the purchase date—not merely on the balance that remains.

Suppose the couple charges $2,000 for furniture on an 18-month deferred-interest card. If the account carries a rate near 30% and the promotional conditions are not satisfied, the resulting interest could approach $700 to $900, depending on the agreement and payment history. A $2,000 purchase can therefore become a $2,700 to $2,900 purchase.

The fine print is where the real terms live. Read it, create an automatic repayment schedule, and aim to eliminate the balance several months before the deadline. Waiting until the final billing cycle leaves no room for a missed payment, posting delay, or calculation error.

4. Buy Now, Pay Later

Buy Now, Pay Later services split a purchase into smaller installments, making the total easy to lose track of. Four payments of $50 don’t feel like $200, even though they are.

The greater danger is stacking several plans:

• Clothing: $50 per month

• Children’s equipment: $75 per month

• Electronics: $100 per month

• Household purchases: $75 per month

Together, those plans consume $300 per month, or $3,600 per year. The Federal Reserve reported that 15% of adults used BNPL in the preceding year and that nearly one-quarter of users had made a late payment.

BNPL is designed to make borrowing feel almost invisible. Before using it, ask whether the purchase would still happen if the entire amount had to leave the checking account today. If the answer is no, the installment plan may be disguising an affordability problem.

5. Buying a Home Versus Renting

This is one of the biggest financial decisions most people make, and it is rarely as simple as “buying is always better.” A mortgage payment can build equity over time, which is a genuine advantage renting doesn’t offer. But buying also involves interest, property taxes, insurance, maintenance, closing costs, and less flexibility to move.

Consider a $400,000 home with 10% down. At a mortgage rate near 6.75%, principal and interest alone would be about $2,335 per month. After adding property taxes, homeowners insurance, maintenance, and possibly mortgage insurance, the actual cost could reach $3,300 to $3,800 per month. A comparable rental might cost $2,300 to $2,700, depending on the market. The purchase could also require $50,000 to $70,000 in upfront cash for the down payment and closing costs.

That does not automatically make renting the better choice. Part of the mortgage payment builds equity, and ownership may provide valuable stability to a family. The right answer depends on how long the couple expects to stay, the local price-to-rent ratio, the property’s condition, and what the down payment could be doing elsewhere. Run the actual numbers for the specific home rather than treating either answer as a rule of thumb.

6. Opportunity Cost: What Else Could That Money Be Doing?

Every dollar tied up in debt has a cost that doesn’t appear on the receipt: what it could have done somewhere else. Carrying a loan isn’t just paying interest. It is also giving up the saving, investing, or financial flexibility that the monthly payment could have provided.

Suppose car loans, personal loans, and financed purchases consume $500 per month. That is $6,000 each year unavailable for other goals. If $500 per month were invested and earned a hypothetical average return of 8%, it could grow to approximately $91,000 after 10 years or $295,000 after 20 years.

Those returns are not guaranteed, but the principle ties much of this list together. The real cost of a purchase or loan is the price tag, the interest, and everything that money didn’t get to do.

7. Savings, Treasury Securities, CDs, Index Funds, and Stocks

Not all places to keep money serve the same purpose. Savings accounts, CDs, and Treasury securities are generally appropriate for emergencies and shorter-term goals because stability matters more than maximizing returns. Broad stock-index funds, including funds that track the S&P 500, may be suitable for long-term goals because they offer greater growth potential but can also fall sharply. Individual stocks add still more company-specific risk.

A young family able to set aside $1,000 per month might direct:

• $500 toward an emergency fund

• $200 toward shorter-term goals in CDs or Treasury securities

• $300 toward diversified long-term investments

As a simple illustration, investing $1,000 per month for 10 years could produce approximately $147,000 at a hypothetical 4% return or $183,000 at 8%, compared with $120,000 in contributions. Neither result is promised.

The goal is to match each dollar to its timeline. Emergency money should not depend on the stock market being favorable when the furnace fails. At the same time, leaving money that will not be needed for decades entirely in a low-yield account can carry its own opportunity cost. This is general information, not personalized financial advice; the appropriate mix depends on the family’s goals, circumstances, and tolerance for risk.

8. Shopping: The $100 Plan That Becomes a $500 Receipt

Some of the greatest damage happens in categories that never feel like serious spending. A Costco or Target trip planned for $100 somehow becomes $500 because everything appears useful, is sold in bulk, or is presented as a deal.

If that happens once a month:

• Planned spending: $100 per month

• Actual spending: $500 per month

• Budget overrun: $400 per month

• Annual overrun: $4,800

A discount is not a saving if it causes the family to buy something it did not need. Use a list, avoid browsing unrelated aisles, and calculate the cart total before reaching the register. For clothing and other nonessential purchases, a 48-hour waiting period can reveal whether the item fills a genuine need or only creates a brief feeling of getting a bargain.

9. Concert Tickets, Games, Shows, and Other Events

Concerts, games, and live shows are genuinely enjoyable and can be worth paying for. The problem is not necessarily the experience; it is the total cost and frequency.

A family outing advertised as $100 per ticket might actually include:

• Three tickets: $300

• Service fees: $75

• Parking or transportation: $40

• Food and drinks: $75

• Merchandise: $60

The $300 event becomes a $550 evening. Six such outings would cost approximately $3,300 per year, or an average of $275 per month.

Budget for the entire experience, not just the advertised ticket price. A dedicated entertainment fund allows the family to enjoy events without receiving the real bill on a credit-card statement weeks later.

10. Travel Is Good—If You Can Afford It

Travel isn’t a trap to avoid. It can be one of the more defensible uses of money because it produces lasting memories and family experiences rather than more household clutter. The caveat is affordability.

A one-week domestic trip for two adults and one child might cost:

• Transportation: $1,000 to $1,500

• Lodging: $1,500 to $2,000

• Food: $700 to $1,000

• Activities and local transportation: $700 to $1,000

That places the total at roughly $3,900 to $5,500 before easily overlooked expenses such as baggage fees, airport parking, pet care, and souvenirs. Saving $325 to $460 per month would fund the trip over a year.

A vacation budgeted for in advance and paid for with savings can be an excellent use of money. The same vacation financed with debt and paid off for the following year is a different financial decision, even if the destination is identical.

11. Online Shopping Every Day of the Week

Online shopping removes nearly every psychological barrier that once accompanied a purchase. There is no drive to the store and no time to reconsider—just a saved card and a button that says “buy now.”

A $20 household order on Monday, $35 of children’s clothing on Wednesday, and a $25 impulse purchase on Saturday may not feel excessive. But three $25 orders per week equal approximately $325 per month or $3,900 per year.

Much of this spending disappears into normal household clutter, which makes its cost even harder to remember. Keep nonessential items in the cart for 48 hours, disable promotional notifications, remove stored payment details, and designate one day per week for online orders. The purpose is not to ban online shopping; it is to restore the pause that convenience removed.

12. Makeup and Personal-Care Costs

Makeup, skincare, salon visits, hair products, manicures, and similar expenses are easy to underestimate because each purchase seems relatively small. Added together, they can become a meaningful recurring category.

A moderate monthly estimate might include:

• Makeup and skincare: $75

• Hair products or services: $75

• Nails or other treatments: $50

That is approximately $200 per month or $2,400 per year. This is not an argument against personal care. It is an argument for making the total visible. Setting a monthly limit, using products before replacing them, and eliminating overlapping subscriptions can reduce the bill without eliminating the routine.

13. Death by a Thousand Cuts

A daily coffee purchase feels harmless—it’s a few dollars, barely worth thinking about. Small recurring purchases add up precisely because no single instance feels significant.

If both adults buy a $6 coffee five mornings per week, the household spends about $250 per month or $3,000 per year. Add lunches, delivery fees, forgotten subscriptions, convenience-store stops, and app purchases, and the small-expense category can readily reach $500 to $800 per month.

None of these pleasures has to disappear. Buying coffee twice a week rather than five times preserves the ritual while saving roughly $1,800 per year. The objective is not to declare every small purchase irresponsible. It is to notice when repeated convenience is quietly crowding out something the family values more.

14. Digital Money: Make Spending Feel Real Again

Paying with physical cash often feels more consequential than tapping a card or phone, and that friction can be useful. Digital payments make transactions convenient but can also make overspending harder to perceive.

Suppose the family spends $2,000 each month across groceries, dining, shopping, entertainment, and personal purchases. If cash envelopes and firm category limits reduce that spending by only 10%, the family retains $200 per month, or $2,400 per year.

Cash does not have to replace electronic payments for rent, utilities, or other fixed bills. It can be reserved for the two or three discretionary categories where spending most often gets away. When the envelope is empty, the category is finished until the next budget period.

15. Track Your Expenses and Know Where the Money Is Going

This is the habit that makes every other item actionable. It’s hard to fix a car-upgrade habit, a Costco overspend, or a coffee run nobody is counting if there is no visibility into where the money actually goes.

If a family spending roughly $6,500 per month finds that just 5% is disappearing into forgotten subscriptions, fees, food waste, duplicate purchases, and impulse spending, that represents $325 per month—or $3,900 per year.

Tracking doesn’t require a complicated spreadsheet. A budgeting app, a bank’s built-in categorization, or a weekly review can work. Sort spending into housing, transportation, food, childcare, debt, shopping, entertainment, travel, personal care, and saving. Then ask which purchases were worthwhile, which would not be repeated, and which category should be capped next month.

The point isn’t to judge every purchase. It is to know, with actual numbers, where the money goes instead of guessing.

The Bottom Line

A young family does not have to eliminate cars, travel, coffee, concerts, makeup, or online shopping. It needs to see their full cost. A handful of deliberate changes—keeping a car longer, avoiding overlapping payment plans, controlling impulse purchases, and tracking expenses—could realistically redirect $500 to $1,500 per month toward emergency savings, debt repayment, education, retirement, or another family goal.

That is $6,000 to $18,000 per year without giving up everything that makes life enjoyable. Saving is not simply about spending less. It is about deciding what deserves the family’s money before convenience, advertising, and easy credit make that decision for them.

Sources

• U.S. Bureau of Labor Statistics, Consumer Expenditures 2024

• AAA, 2026 Your Driving Costs analysis

• Federal Reserve, Economic Well-Being of U.S. Households in 2024

• Freddie Mac Primary Mortgage Market Survey

The course walks through setting a realistic budget, defining your property requirements, comparing different types of homes, and using online tools to research properties and markets. It also examines the role of real estate agents, how commissions work, what to consider when choosing an agent, and how research and negotiation can help buyers navigate the search and offer process more effectively.

From there, the focus shifts to the financial mechanics of homeownership. You’ll explore down payments, mortgage insurance, interest rates, loan options, amortization, refinancing, and loan recasting, along with the many costs that extend beyond the monthly mortgage payment. The course also considers the risk of becoming “house poor” and why understanding affordability—not simply how much you can borrow—is essential when determining how much home to purchase.

Finally, the course takes a longer-term view of the decision. You’ll examine new versus older properties, maintenance and ownership costs, home appreciation, the time and financial commitment involved in owning a property, and the tradeoffs between putting money into a home versus renting and investing elsewhere. Together, these topics provide a broader framework for evaluating a home not only as a place to live, but also as a significant financial commitment and long-term investment.

Takeaways

1. Renting vs. buying is a financial and lifestyle decision — compare the true long-term costs, benefits, and opportunity costs before choosing.

2. Affordability goes beyond what a lender approves — consider your income, lifestyle, savings, other obligations, and the risk of becoming “house poor.”

3. Budget for more than the down payment and mortgage — closing costs, taxes, insurance, maintenance, repairs, HOA fees, and eventual selling costs can significantly affect the economics of ownership.

4. Understand how mortgages actually work — interest rates, APR, amortization, loan terms, points, PMI, equity, and monthly payments all influence the true cost of borrowing.

5. Loan structure matters over the long term — choosing between loan terms such as 20 or 30 years can substantially change monthly payments, equity accumulation, and total interest paid.

6. Know your options after purchasing — refinancing and recasting can potentially reduce borrowing costs or monthly payments as your financial situation or interest rates change.

7. Research the property and the surrounding market — property type, age, condition, location, schools, commute, amenities, and local market conditions can all influence desirability and long-term value.

8. New and older homes involve different tradeoffs — newer homes may offer customization and lower initial maintenance, while older homes may come with different pricing, locations, and repair requirements.

9. Use technology to become a better-informed buyer — property platforms and online research tools can help compare listings, neighborhoods, prices, features, and market activity.

10. Understand the role—and cost—of real estate professionals — learn how agents and commissions work, choose representation carefully, and recognize how much research you can perform independently.

11. Inspections and due diligence are critical — understanding a property’s condition before purchasing can help uncover potential repairs, expenses, and risks.

12. Negotiation is an important part of buying a home — your leverage can vary depending on the property, seller, market conditions, and whether you’re purchasing an existing, new-construction, or spec home.

13. Homeownership can build equity and benefit from appreciation, but neither should be assumed — evaluate potential returns alongside financing costs, maintenance, transaction expenses, and alternative uses for your money.

14. Approach a home purchase as both a lifestyle and financial decision — the right property should meet your living needs while fitting comfortably within your broader financial plan.

15. Be patient and avoid rushing the purchase — buying a home takes time, and carefully comparing properties, financing options, and long-term costs can help prevent an expensive decision you may later regret.

Watch on Computer

You should receive an email with course details within 96 hours of purchase. If you don’t see that email in your inbox shortly, check your spam folder. If you don’t find it there either, reach out to varun@getsnowpal.com.

Buy $64.99

Watch on Mobile App

Prefer to watch it on the go? We’ve got you covered. Download our Mobile App from the App/Play Store, and all our courses are available there as well.

Download from App Store

Download from Play Store

More Courses

Check out our other Software, Finance, and AI courses on the Snowpal Education page.

AI + Snowpal API: Reduce Time to Market

Podcast

Own Your Weights: The Real Economics of Private AI — on Apple and Spotify.

Introduction

A conversation between host Krish and guest Sam Sammane, founder and CEO of Quantum General Intelligence (QGI) and author of The Singularity of Hope.

Sammane brings an unusual vantage point to the discussion: two decades in symbolic AI and automated theorem proving in the late 1990s, followed by a career in mergers and acquisitions, before returning to AI full time in 2022. Across the conversation, Krish and Sammane cover the real gap between frontier and open-source model performance, the economics and security tradeoffs of Chinese open-weight models, why coding and agentic workloads call for different tools, and the growing business and national case for private, sovereign, and deterministic AI infrastructure that companies and governments own outright rather than rent.

Every few months, a new leaderboard claims to settle which large language model is “best.” But according to one AI founder with a two-decade history in symbolic reasoning and automated theorem proving — a discipline that predates the current generative AI boom by twenty years — the leaderboard question is the wrong one. The more consequential question for any company deploying AI in production is who owns the model, who controls its weights, and what happens when the vendor changes the rules.

This article distills a wide-ranging technical discussion covering the evolution from symbolic AI to today’s hybrid, tool-using “agentic” systems; the real gap between marketing claims and coding performance across frontier labs; the rise of cheap, high-quality open-weight models out of China; and the practical, cost-driven case for private and sovereign AI infrastructure once a company crosses a certain size. Throughout, one theme recurs: renting a frontier model is convenient, but ownership is what protects a business from deprecation, policy bans, and vendor lock-in.

From Symbolic AI to the Agentic Revolution

The speaker’s background sits outside the neural-network mainstream. In the late 1990s and early 2000s, he worked on automatic theorem proving and symbolic simulation for hardware design — a field colleagues at the time dismissed as “too theoretical” for anyone to care about. He left academia for consulting and mergers and acquisitions, running three separate testing-lab businesses over two decades, before a 2022 encounter with ChatGPT sent him back into AI full time.

“In 25 years ago, I built a certain symbolic AI that can handle 65,000... tokens as a context window. And people told me that’s nothing. ChatGPT in 2022 was handling 8,000.”

That background turned out to be an advantage rather than a liability. Generative AI in 2023 was purely neural; his own expertise was in the older symbolic tradition. Blending the two, ahead of the industry’s own shift toward hybrid, tool-augmented “agentic” architectures, became the founding thesis of his company, Quantum General Intelligence (QGI). Of the roughly 80,000 AI startups he estimates exist today, he argues barely a hundred are doing substantive technical work — the rest are thin prompt wrappers around someone else’s model.

The Illusion of “Open” and the Real Leaderboard

The discussion is unsparing about naming conventions and marketing in the industry. “Open AI,” he notes, is now a closed company — one that began as a nonprofit funded by a $50 million donation from Elon Musk and later converted to a for-profit structure despite reporting tens of billions of dollars in annual losses. “Deep learning” and “neural networks,” in his view, are wishful branding for decades-old statistical input-output modeling, not literal replicas of biological cognition — and he is emphatic that no current or near-term system qualifies as artificial general intelligence in the science-fiction sense.

On model quality specifically, he draws a sharp line between public benchmarks and his own internal testing, developed by stress-testing models against real coding and agentic tasks at his company:

“According to [the press], always Chat GPT models are the best. And I’m sorry to tell OpenAI like this plainly: you don’t know how to code. Your models are stupid... A small Chinese model is better than that.”

His actual ranking: Anthropic’s Claude (”Fable” in the transcript) leads decisively on coding quality, followed closely by xAI’s Grok 4.6 (built on the former Cursor codebase following its acquisition). For agentic work that isn’t complex software engineering, he argues the gap between frontier and low-cost open-weight models has essentially closed.

The Open-Source Insurgency

DeepSeek’s release is described as a watershed moment for the industry — not because it beat frontier models outright, but because a five-million-dollar company demonstrated a near-frontier model at a fraction of the cost, breaking the assumption that only labs with billions in capital could compete.

“Deep Seek... was the best thing happened for the AI industry. It started somehow a new era when we had OpenAI, arrogant as they are, pretending we have AGI in two years.”

He’s equally direct about the security anxiety surrounding Chinese models, distinguishing between hosted Chinese applications (which he says frequently phone home to servers in China) and open-weight models a company downloads and runs itself: “If you are familiar with the technology of AI, that’s all what you need to run the model... open source is not open weight — okay, it’s not [the same thing]. But in the practicality, it is.” His current recommendation for cost-sensitive agentic workloads points to Alibaba’s Qwen family, alongside DeepSeek V4, Moonshot AI’s Kimi/K3 line, and Zhipu’s GLM-5.3 — models he says cost roughly one cent per million tokens against fifty dollars per million for top-tier proprietary models.

Coding vs. Agentic Work: Different Tools for Different Jobs

A recurring practical distinction: use the best available model for coding, and the cheapest viable model for everything else.

“It’s like bringing Einstein to your office... if you are building something that needs Einstein, and coding is complex.”

For software generation specifically, he places Claude ahead of OpenAI’s Codex and his own company’s in-development coding assistant, Quark. But for agentic workflows — research, writing, classification, orchestration — he argues that tiny open-weight models like Qwen 3.8 are close to indistinguishable from frontier models like Opus 4.6 in practice, while costing orders of magnitude less per token.

The Business Case for Private AI

The private-AI argument is framed around company size and risk exposure rather than ideology. Below roughly fifty employees, he argues, building private infrastructure is a distraction; above that threshold, renting model access starts to look like a strategic liability.

“It’s like someone who preferred to rent a Ferrari over buying a Volkswagen because he wanna appear cool. Yes, he will appear cool, but you cannot have it all the time.”

The risk isn’t hypothetical: he describes being banned outright by a commercial AI provider over a misclassification of his company’s activity, cutting off access to data and workflows built entirely on that vendor’s platform. His broader point is about vendor dependency: a company that builds its operations on a rented model has no recourse when a provider changes pricing, deprecates a model version, or revokes access — a risk he says is fundamentally different from consumer software, because it touches a company’s operational intelligence rather than its entertainment.

On the economics of self-hosting once at scale, he cites an internal example: an engineer running 280 million tokens per day of agentic (non-coding) workload against a self-hosted open-weight model, on a GPU server costing roughly $600 per month — compute cost effectively at zero beyond the fixed hardware bill.

Deterministic AI and the Role of the Human in the Loop

Despite his enthusiasm for automation, he rejects “vibe coding” — the idea that a business can be run purely by prompting an AI without a human who understands the system — as a scam premise.

“AI will never propose to you [an intent]... it will put the constitution in the repository, and it will not change it, even if you [ask new questions ten days later]... that’s against our policy. Who wrote the policy? You — but it’s an AI.”

Every private-AI deployment, in his framing, needs a dedicated human owner — a CTO or a contracted AI specialist responsible for the tool contracts, input-output relationships, and standardization layers between the model and the business logic. That role, he notes, does not need to be co-located or full-time, since remote specialists can service multiple companies simultaneously.

Rethinking Education Around Intuition and Critical Thinking

The conversation closes on education, where he argues that traditional assignments — the five-paragraph essay in particular — have been rendered obsolete by AI in the same way calculators made mental arithmetic drills obsolete. His proposed replacement is a curriculum built around what he calls the “educated guess”: human intuition sharpened by domain expertise, which he argues remains a form of intelligence current AI systems cannot replicate.

“Your guess is a very strong form of intelligence that we don’t know how to replicate... we don’t have it in the machine. This is our superpower.”

The goal, in his words, is teaching people to be human again rather than to behave like machines — since decades of institutional education optimized students for the kind of rote recall and procedural compliance that AI now performs by default.

Sovereignty as a National Strategy

The same private-versus-rented logic scales up to nation-states. He argues governments should build their own fine-tuned, sovereign AI systems on top of open-weight foundations rather than depending on commercial providers, whose models he characterizes as commercially biased despite public claims of neutrality.

“You cannot rent intelligence. That’s basic, but it’s true. Any human will not love to bring someone and tell him, ‘Now for my life I will not think anymore, you think for me.’”

He singles out the United States as notably exposed on this front — among the world’s most AI-advanced nations, yet without a government-operated foundation model independent of private commercial labs.

Technologies

The conversation moves across a wide field of proprietary and open-weight language models, spanning US, Chinese, and independent labs. For reference, the models and coding assistants discussed by name include:

• ChatGPT / GPT models — OpenAI’s consumer and API-facing model line

• Codex — OpenAI’s dedicated coding assistant

• Claude (including Claude Opus 4.6 and Claude 4.5) — Anthropic’s model family, described as the current leader in coding quality

• Claude Code — Anthropic’s AI coding tool

• Grok 4.6 — xAI’s model, built on the former Cursor coding assistant following its acquisition

• DeepSeek (V3 and V4) — DeepSeek’s open-weight models, credited with triggering the current open-source AI race

• Qwen (including Qwen 3.8) — Alibaba Cloud’s open-weight model family

• Kimi / K3 — Moonshot AI’s model line

• GLM-5.3 — Zhipu AI’s model

• Mimo — Xiaomi’s open-weight model

• Llama — Meta’s open-weight model family, referenced generically as one of the “smaller models” now competing in the space

• Quark — Quantum General Intelligence’s own coding assistant, not yet publicly released

Summary

The throughline across this discussion is a distinction between renting intelligence and owning it. Frontier proprietary models remain the strongest choice for complex software engineering, but for agentic and general business workloads, the practical gap between expensive frontier models and cheap open-weight alternatives — largely originating from Chinese labs — has narrowed dramatically. Companies above roughly fifty employees are advised to weigh the ongoing risk of vendor dependency, pricing changes, and outright access bans against the fixed cost of hosting fine-tuned, open-weight models on owned or rented GPU infrastructure. None of this removes the need for human oversight: a dedicated AI-responsible role remains essential to translate business intent into working systems, since no current model can infer what a company actually wants. And the same logic that applies to individual businesses, the discussion argues, applies to national governments — sovereignty over one’s own models is becoming as strategically important as owning any other piece of critical infrastructure.

Read more

On a recent episode of the Snowpal Podcast, Krish Palaniappan sat down with Gerard Holland, a chartered accountant turned tech entrepreneur and founder of Talent Match Africa (TMA), to make the case for a “next frontier” that most Western businesses have barely considered: Africa.

AI + Snowpal API: Reduce Time to Market

Podcast

Africa, AI, and the Future of Global Talent — on Apple and Spotify.

Introduction

Holland, who lives in Melbourne, Australia, but runs operations out of Johannesburg, Durban, Cape Town, Nairobi, and Addis Ababa, didn’t set out to build an Africa-focused talent company. His path started in international education, building an internship placement platform that he took from Australia to the UK and Canada. Everything changed in 2020, when he was introduced to the continent through Zondwa Mandela, a grandson of Nelson and Winnie Mandela.

“I’d never been to Africa, but it definitely ignited something inside of me, an interest and that entrepreneurial flair, you could call it,” Holland recalled. He flew into Ethiopia first, then Rwanda, Kenya, and South Africa. What he found didn’t match his expectations at all: “I was completely blown away by the talent that is on the continent, the level of English proficiency, the tech capability, education levels, the infrastructure that’s happening in Africa. It wasn’t what I expected in my head.”

Talent Match Africa was born from that trip. Today the company places people in tech, finance and accounting, sales support, customer service, legal support, logistics, and operations roles with companies across the US, Australia, Canada, the UK, France, and China — and increasingly, in AI-related work.

The Demographic Case for Africa

Holland’s pitch for Africa starts with numbers most business leaders haven’t encountered. By 2035, every second person entering the global workforce will live on the African continent. By 2050, the continent’s population is projected to reach two billion. The driver is age: the average age in Africa is 19, compared to the 40s in the US and 72 in Monaco. That young population is now flooding into the workforce, backed by millions of university graduates every year.

Crucially, that talent pool is largely untapped. “India has become very congested and saturated,” Holland said. “The US went in the 70s and 80s and helped India become this tech powerhouse. But now it’s very saturated because everyone’s there. Whereas people haven’t quite worked out yet that there’s amazing talent in Africa. So you don’t have that competitive pressure. Price becomes more favorable, access to really good talent.”

He also pointed to a retention advantage Africa currently holds over the Philippines, where job-hopping has become endemic. “You don’t have people moving around as much... We’re not having those issues in Africa. Not yet anyway. We’re probably five years away from when that may become a problem.”

“Africa Is Not One Country”

Palaniappan pushed back with an obvious question: Africa is a continent of more than fifty countries, spanning enormous cultural and linguistic differences. Isn’t that a barrier for companies trying to figure out where — and how — to hire?

Holland pointed to a book that shapes his own thinking: Africa Is Not One Country. “A lot of people do sometimes think about Africa as being a country, when it’s like saying Europe is a country,” he said. “People in Germany are very different to people in France. And they’re next to each other.” A company that wants French-speaking talent needs to look at specific regions; language, accent, and business culture all vary sharply from country to country.

Accents, in particular, have become a bigger consideration than Holland expected. “I’m finding more and more that accent is even more important, particularly for a lot of USA companies. I’ll often get calls from businesses saying, ‘Look, Gerard, we really want people, but just so you know, we need really neutral accents.’ Where if they’re talking to clients, we don’t want people to know that they’re from another country — Americans want to deal with Americans.” South African, Kenyan, and Nigerian accents are all distinct, he noted, and clients increasingly specify which they’re comfortable with.

For companies looking to enter the continent, Holland recommends South Africa as an entry point: “It’s probably the most westernized of a lot of the countries in Africa. So a lot of businesses will get a foothold in South Africa and then they might work up into different parts of the continent.”

The Affordability Equation — And Why It’s Shifting

Palaniappan asked Holland directly whether Africa’s core value proposition, like India’s before it, ultimately comes down to cost. Holland didn’t dodge the question.

“India has become a lot more expensive now,” he said. “Eight, nine years ago, India was still very, very affordable. With all the demand on talent, people know what they’re worth and they can ask to be paid more, which then costs go up.” He described clients who saw quarterly price increases of 15% just to keep pace with local wage inflation. Africa, by contrast, is earlier in that cycle — global demand hasn’t yet driven up local wages the way it has in India, though Holland noted that large employers like Google and Amazon are already establishing a presence on the continent.

He also pointed to a cultural shift in how openly companies discuss offshoring. “Pre-COVID, it was almost like businesses when they talked about offshoring, it was a bit taboo... Now, post-COVID, people are like, ‘Yeah, I’ve had 20 people in Bangalore for 10 years.’” Rising costs of living in the US, UK, and Australia have made the math increasingly unavoidable for businesses trying to stay profitable: “If you can get someone doing the exact same job, but it costs 70% less, then businesses are saying, well, I’m going to do that.”

Underlying all of it, in Holland’s view, is a shift in trust that COVID accelerated. “What COVID made everyone appreciate... is that I can trust my people working remotely to do their job if we’re tracking the outcomes of what they do. If I’m in Boston and I’ve got a team member in Boston that’s working from home anyway, well why can’t I have a team member in Johannesburg or Bangalore doing the same work?”

The AI Question: Does Cheaper Labor Even Matter Anymore?

The most pointed exchange of the conversation came when Palaniappan raised what he called playing “devil’s advocate.” If AI is allowing companies to do the same work with a fraction of the headcount — he cited an example of a company that reportedly went from 52 employees to eight — does the whole premise of chasing cheaper labor abroad start to break down? If you only need eight people, why not just hire eight people locally?

Holland’s answer was refreshingly candid about the uncertainty in the room. “I don’t think anyone has the answer yet. Every business I speak to now has a different perspective on it.” He described playing golf with a business owner who’d cut his team from 22 to 12 while becoming more profitable than ever, driven by AI efficiency — and, in the same breath, other businesses that tried to cut headcount with AI and had to reverse course and rehire because “the AI wasn’t the efficiency they thought they would get.”

Holland laid out two divergent futures he sees as plausible. On one end: mass unemployment. “We actually need way, way less people across the entire economy, and we end up at 25, 30 percent unemployment globally. That’s a pretty drastic position. It’s not impossible. I think it’s a low probability, but it’s not impossible... The USA cannot possibly survive with more than 20 percent unemployment. The country will implode on itself.”

On the other end is a more optimistic scenario, and it’s the one Holland is building his business around: AI as an equalizer for the developing world. “If we can have people that are based in South Africa, Kenya, Philippines, Colombia — doesn’t matter — and you upskill them with the latest tools... they can perform at two to three times higher than what they otherwise would have three years ago. And then all of a sudden you can have lower-cost resources doing the same work but at a higher level than previously possible.” For a business owner, he added, “this is amazing — I can get people that are much more affordable, doing work at a really high level because they’re using AI tools.”

He offered a concrete example: a client in Toronto had built out 20-25 AI agents running parts of their business, with the CEO and CFO each managing some directly. But agents need constant supervision. “You have to actually manage them. They break, something’s not working, you need to fine-tune it... it’s not a ‘you do it once, you leave it there, and happy days, you go sit on a beach while your business makes all this money.’” TMA now has two people in Johannesburg dedicated to managing that client’s AI agents — a role that didn’t exist a few years ago.

He also shared a striking data point from a French airline-software client: “Of their thousand engineers, no one writes code anymore. Literally no one writes a line of code. They’re all reviewing code. They’re all on their phones watching the code build.” That shift, Holland argued, is changing the profile of the talent companies need — not less experienced people, but more experienced ones who can supervise AI output. “So rather than getting very early-stage grads who don’t have the experience yet, it’s actually targeting the people who do have a lot of experience... We can go and target the top 10 percent. It’s harder to do in India now because the top 10 percent are getting paid a lot of money. We don’t have that saturation in these markets at the minute.”

Summing up the uncertainty, Holland offered one of the conversation’s sharper lines: “There’s this saying that you’ve probably heard — AI won’t take your job, but someone using AI will take your job.”

Beyond the Bottom Line: Culture, Trust, and Why Remote-Only Failed

Palaniappan raised a challenge that goes beyond skill or price: the fatigue that comes with building trust across cultural and geographic distance. Holland admitted TMA learned this the hard way. “When we first took the business into Africa... we did a work-from-home model, and it was a disaster. It didn’t work 98 percent of the time.” The fix was physical offices: pristine, well-equipped spaces in each city where TMA’s talent works alongside other engineers, marketers, and business professionals, creating a sense of team and accountability that pure remote work didn’t provide. It also lets TMA intervene directly when something’s off: “We’ve got managers on the ground that can actually go and sit next to them and have a coffee and say, what’s happening? Your performance has dropped off. Is there something we need to know about?”

But Holland was clear that the deeper responsibility for culture sits with the client, not the vendor. “That always comes down to treating people no different if they’re based in Johannesburg or they’re based in Seattle. It’s how they bring them into team meetings, how they speak to them the same as they would speak to any employee. If you foster a nice culture like that, you get loyalty and longevity, and then you get better results as well. But it does take effort.”

Entrepreneurship and Creativity: Is Africa Just Playing Catch-Up?

One of Palaniappan’s more provocative questions was whether developing economies are destined to remain in a support role — providing affordable labor to execute someone else’s vision — rather than originating new ideas themselves. Holland pushed back, pointing to Africa’s fintech sector as evidence of homegrown innovation. “MPESA was actually developed before WeChat, and it’s a full financial system that sits on an app on your phone... Nigeria has a huge tech entrepreneurial startup scene.” He described a grassroots hustle culture across the continent: “Most Africans I meet have a side hustle. By nature, there’s this hustle entrepreneurship mentality.”

He does concede the obvious gap: Africa isn’t attracting Silicon Valley-scale venture capital. “There’s not like the unicorn VC money — people aren’t putting five billion dollars into a company like you are in Silicon Valley.” But he sees AI tools lowering the barrier to entry for African founders in a way that could change that calculus over time: “Now you don’t need capital to go and build a startup. You don’t need to go and hire engineers to build an idea that you’ve got. You can get a license to Claude Code, put a certain amount in per month, and go build it.”

The Perception Problem

Asked about political stability, Holland said he’s personally never run into trouble operating in the countries where TMA works. His bigger concern is reputational, not operational — specifically, how migration coverage in Western media shapes perceptions of Africa as a business partner. “I think what the bigger issue is now is what’s happening in the media around migrants... it’s too often being pointed at — it’s someone from Africa, it’s someone from Morocco. And it’s only telling part of the story... That’s not the real Africa that I know.”

He argued that this narrative directly complicates his sales pitch: “It makes my life more difficult because I’m convincing businesses to look to Africa for their global resourcing. But if all they’re seeing on the news is that migrants are causing problems in their own country, and those migrants are from Africa, then that subconsciously or consciously changes their view as to whether they want to engage with people from the continent.” He turned the lens back on the US as well, noting the political polarization he’s observed there: “I’ve never seen — I mean, the US — I’ve never experienced before, the last probably four years, is almost a hatred between political parties... there’s a lot of things simmering underneath the surface in America.”

Krish’s Own Playbook

Toward the end of the conversation, Holland turned the tables and asked Palaniappan why he wouldn’t look to Africa when adding resources to his own US-based company. Palaniappan laid out his personal decision hierarchy: local talent within driving distance first, for the value of in-person connection; then talent elsewhere within the US; then, if cost becomes the deciding factor, international markets — where he’s worked with people in the Czech Republic and Ukraine, and extensively with talent in India, drawing on his own upbringing there to navigate regional differences in colleges, credibility, and culture.

His core caution about outsourcing to any new region, Africa included, wasn’t about talent quality — it was about the ongoing relational work required to make a distributed team function, even when AI is doing much of the technical heavy lifting. “Even if you’re building software, even if you’re using AI to build software, you don’t actually hire a developer like you did three years ago. There’s still a lot of conversation that needs to happen constantly so you’re building the best quality software... There’s got to be a connect, or lack of disconnect, between your team and that person or those people.”

He also named a practical awareness gap that Holland’s business exists to solve: most people, he noted, can probably name fewer than twenty of Africa’s roughly fifty-eight countries, let alone distinguish the talent, culture, working norms, and political context of South Sudan versus Mauritania versus Kenya. “If there’s a way to bridge that gap, I can see more people wanting to explore this as an option, so they don’t feel like they’re coming from a place of being ignorant about who they’re going to be potentially working with.”

Holland’s closing point tied the whole conversation together: the decision calculus for every business leader now runs through AI first. “A lot of decision-makers, well, how does — can AI automate it? If not, how do I have someone that can help me use AI to do it? If not, what’s the human I need to do it? And then how much does it cost? We all as business professionals are weighing that up all the time.”

Closing Thoughts

What emerges from the conversation isn’t a simple sales pitch for African outsourcing — it’s a picture of an industry in flux, where the old logic of “cheaper labor, same work” is being rewritten by AI in real time, and where the winners may be the regions that combine affordability with rapid AI adoption rather than those competing on cost alone. Holland’s bet is that Africa, still early in its global-talent journey and unburdened by the wage saturation now facing India, is positioned to make that leap.

Gerard Holland is the founder of Talent Match Africa. More information is available at talentmatchafrica.com.

Viktor Popovic has closed two very different kinds of impossible sales. The first was convincing an old-school pressure washer manufacturer, in 2003, that people would actually buy heavy equipment over the internet. The second, twenty years later, is convincing payment processors to compete against each other in real time for the same merchant. Between those two sales sits a masterclass in what it actually takes to sell something the market isn’t ready to buy.

AI + Snowpal API: Reduce Time to Market

Podcast

How One Founder Cracked Two Impossible Sales — on Apple and Spotify.

The first sale is never the one you planned for

Viktor didn’t set out to sell pressure washers. He’d built a list of roughly 40 products tied to the aviation industry — his original field of study — but a keyword analysis run by his business partner turned up an unexpected signal: “pressure” had unusually high search volume. One of the aviation-adjacent items on his list happened to be a pressure washer used for cleaning hangar floors. That accident of keyword research became a 21-year business.

“A friend asked me if I wanted to start a business. Without a second thought — yes, I'm ready. Why not?"

But finding the product was the easy part. The real sales problem was upstream: getting manufacturers to trust an unproven sales channel. In 2003, the standard model was regional reps who drove vans full of equipment around town, pulled machines off the truck, hooked up a garden hose, and demoed them live. Viktor was asking manufacturers to abandon that entirely and hand their equipment to a stranger promising to sell it through a browser. It took him six months to land his first vendor, a company called Cam Spray out of Iowa. The first actual sale — a cold-water diesel-powered pressure washer to a U.S. military base in San Diego — came down to a simple phone call and a fast, confident shipping quote.

The lesson he draws from it: the hardest sale often isn’t to the end customer. It’s convincing the party one step removed — the vendor, the partner, the gatekeeper — that a new way of doing business is worth the risk.

The second time around, he was wrong about what would be hard

When Viktor started Avendo, a fintech SaaS company that lets credit card processors compete for merchant transactions in real time, he assumed the sales motion would be straightforward. Merchants would obviously want lower processing rates. Processors would obviously want to compete for that business. “Why wouldn’t they love this idea?”

He was wrong. Payment processors have run the same playbook for 50 to 60 years: evaluate a merchant, assess risk off their statements, quote a flat rate, done. Avendo was asking them to shift into a model where they compete for the same merchant’s business transaction by transaction. That’s not a product objection — it’s an identity objection. It took Viktor seven or eight reworked pitches to find language that got processors past their blind spots and objections before the idea started to click.

“I thought the sales process would be where I need to worry, that everybody would be on board because the idea is great — why not? Man, was I wrong. It's actually the hardest part: getting payment processors to change the way they think, because they've been doing business this same way for the last 50-60 years.”

Notably, once it did click, it clicked fast — because the pitch to merchants and referral partners is genuinely simple: save 1% on a million-dollar-a-year processing volume, and that flows straight to net margin. Decision-makers get it in one sentence. The friction isn’t in the value proposition. It’s in getting the party whose behavior has to change to actually change it.

Referral partnerships beat cold outreach — but only after the failures teach you why

Before landing on what works, Avendo ran seven or eight different marketing motions in parallel: cold email, referral partnerships, paid advertising, and more. Viktor is candid that most of it didn’t work on the first try. One cold-email platform was pulling leads from what turned out to be a stale database — they were spending real money generating zero responses before they figured out the list itself was the problem. Email deliverability issues meant learning to run domain warm-ups, rewrite subject lines, and rebuild sender reputation from scratch.

What eventually worked was narrowing to three referral partner types who already understand net margin economics well enough to sell on Avendo’s behalf without much friction: business consultants and coaches, fractional CFOs, and accounting firms. These partners refer their clients into Avendo, and Avendo reciprocates leads back to them with client approval — a two-way referral loop built on partners who don’t need convincing on the math.

The broader point: there’s no way to know in advance which channel will work. The only path is running several simultaneously, tracking results honestly, and being willing to kill a channel that isn’t converting rather than defending the plan for its own sake.

80% planning, 20% execution — and still 70% wrong

A mentor once told Viktor that a well-run initiative is 80% planning and 20% execution — get the plan right and the execution mostly takes care of itself. He believes it, and he still spent months in heavy planning before launching Avendo. And yet roughly 70% of that original plan changed once reality intervened.

That’s not a contradiction. The planning wasn’t wasted just because the specifics changed — it forced him to actually understand the payment industry’s layers (network fees, acquiring banks, issuing banks, card types, government and gift cards) instead of assuming his merchant-side experience had already taught him the business. Planning, in his framing, isn’t about predicting the future correctly. It’s about doing the homework deep enough that when the plan breaks, you know enough to fix it fast.

Resilience is a skill, not a personality trait

Viktor doesn’t describe himself as naturally thick-skinned. He describes himself as built that way by repetition — pitching processors seven or eight different ways, absorbing rejection after rejection, and treating each “no” as information about a blind spot rather than a verdict on the idea. His practical advice for staying in a sales grind that isn’t paying off yet: celebrate small wins deliberately. Hiring the right person, closing one meaningful account, hitting a minor milestone — mark it, even briefly, because the wins that matter get lost if you’re only measuring against the ten-million-dollar outcome still years away.

The takeaway for anyone selling something the market doesn’t understand yet

Two sales, two decades apart, same underlying pattern: the product wasn’t the obstacle. The obstacle was convincing someone whose business model, habits, or risk tolerance had to change. Viktor’s approach to both is the same — treat every rejection as a missing data point, keep reworking the pitch until it lands, lean on partners who already understand your economics, and measure progress in small wins rather than waiting for the finish line to feel good.

“It's just trial and error, I think that's the bottom line. I don't think there's a secret to it, or a crystal ball you can look at.”

As he put it on the podcast: don’t get discouraged. “Not him — let’s go tweak something, do it this way.” That, more than any framework, is what got two very different sales across the line.

Summary

For sales engineers evaluating go-to-market motion design: the core signal from this conversation is that objection surface area scales with how entrenched the incumbent workflow is, not with product complexity — Viktor’s hardest technical sell wasn’t a feature gap, it was displacing a 50-60 year old risk-assessment heuristic (flat-rate quoting off a merchant’s statements) with a real-time, transaction-level competitive bidding model, which required rebuilding the champion’s mental model before any pricing conversation could land; his resolution path was iterative pitch-architecture testing (seven to eight distinct framings) to identify and patch objection blind spots rather than optimizing a single script, paired with a channel-attribution pivot away from cold outbound (killed by stale list decay in a purchased database, undetectable until response-rate analysis surfaced it) toward a referral-partner model selecting for partners who already carry the requisite domain literacy — fractional CFOs, accounting firms, consultants — so the value prop (basis-point margin capture at the transaction level) requires zero re-education before it converts, which is the throughline: reduce time-to-comprehension for the buyer by routing through intermediaries who’ve already internalized your unit economics, rather than trying to compress that education into the pitch itself.

A quick reference for the questions we get most often about the Snowpal product suite.

General

What is Snowpal? Snowpal is a Backend as a Service (BaaS) company. We build APIs that help other companies reduce the cost, risk, and effort of building software, so they get to market faster. On top of those same APIs, we also run two of our own consumer-facing products: a Project Management platform and an Education platform.

What’s the difference between Snowpal’s APIs and Snowpal’s apps? The APIs are the B2B side of the business — production-grade backend infrastructure that any company can integrate into their own web, mobile, or server-side apps, regardless of industry or tech stack. The Project Management platform and Education platform are B2C products built on top of those same APIs, so when you use them, you’re using thoroughly vetted systems already running in production.

APIs

What APIs does Snowpal offer? Our APIs are LIVE on AWS Marketplace, and include:

• Building Blocks API – a generic API providing the foundational pieces to build almost any system

• Content Management API – for managing content-heavy applications

• Project Management API – for building project management features or full platforms

• Classroom API – for managing classes and students, built for the teaching community

• Status API – for building status-tracking features (think a Slack-status-style app)

• Conversation API – for adding in-app conversations

• Custom Attribution API – for supporting virtually any form

• Access Control List API – for securing apps without building access control from scratch

Together these total thousands of endpoints, and we’re adding more regularly.

Who are the APIs for? Any company building a web app, mobile app, or server-side component/microservice — regardless of industry. The APIs are domain-agnostic where possible (Building Blocks) and domain-specific where useful (Project Management, Classroom, etc.), so teams can pick what fits.

What languages/SDKs are supported? We currently provide SDKs for Golang, with more languages planned. Full API guides, references, and recipes are available at developers.snowpal.com.

How do I get started with the APIs? Three steps: subscribe to the API, import our Postman Workspace (Sample API on Postman), and use your API key plus product code to start making requests.

Education

What is Snowpal Education? An education platform with 50+ affordable, hands-on courses, mostly in software development and architecture, plus a growing set of business, finance, and stock-trading courses. Courses are available on the web and on our mobile apps.

How long and how much are the courses? Most courses run 30–90 minutes and are priced under $10 — the goal is hands-on, practical learning for less than the cost of a coffee.

What topics are covered? Software and architecture topics include things like AWS API Gateway, Postman, Flutter, serverless (AWS SAM), DynamoDB, microservice security, multi-tenant architecture, OAuth 2.0 social login, and REST API fundamentals. Business and finance courses cover stock trading basics (getting started, buying/selling/shorting, portfolio management, research) and running a SaaS business.

Can I get a custom course or 1:1 mentorship? Yes — we offer custom-built courses tailored to your needs, and you can book time directly with our CTO for code review or consulting.

Is there a revenue-share option for course creators? Yes, we host courses for free and split revenue 80/20 with creators.

Who uses the Classroom API vs. the Education platform? The Education platform is where individuals go to take courses. The Classroom API is for developers and institutions who want to build their own class/student management tools — for example, an EdTech company building its own app on top of Snowpal’s backend.

Project Management

What is Snowpal’s Project Management product? A project management platform — available as a web app and mobile app — built on our own Project Management API. You can use it directly at snowpal.com, or integrate the underlying API into your own product.

What can I do with it? Organize work using a flexible hierarchy: Keys (containers, like Projects or Boards) contain Blocks (foundational building blocks), which contain Pods (a further level of detail). You can manage tasks, checklists, comments, notes, attachments, and favorites, link related content with symbolic links, grant collaborators Read/Write/Admin access at the Block or Pod level, and build custom charts and dashboards.

Is it available on mobile? Yes — Snowpal’s apps are available on the App Store and Play Store, in addition to the web app.

Can I build my own project management tool instead of using yours? Yes. The Project Management API that powers our own platform is available for you to integrate directly, so you can build a custom web, mobile, or server-side solution rather than using our hosted app.

Managed Services

Does Snowpal offer anything beyond self-serve APIs and products? Yes — we offer Managed Services for teams that want hands-on help integrating our APIs or building on our platforms, rather than doing it entirely self-serve.

How do I get in touch? Book a meeting, or email varun@snowpal.com.

Have a question that’s not covered here? Reply to this post or reach out to us.

In this episode, ⁠Krish Palaniappan⁠ speaks with ⁠Brian Samson⁠, founder of ⁠Plugg Technologies⁠, about the evolving landscape of remote work, particularly in the context of nearshoring and offshoring. Brian shares insights on the benefits of hiring talent from Latin America, the cultural nuances that affect remote collaboration, and the importance of a rigorous hiring process to mitigate risks associated with international hiring. The conversation delves into the value of talent beyond cost savings and the challenges faced when hiring from different countries.

• Originally featured on the Snowpal Podcast with Krish Palaniappan

• Guest: Brian Samson, Founder of Plugg Technologies

Most companies weighing nearshore hiring ask the wrong question first. They ask how much cheaper it is, when the question that actually determines whether the decision pays off is how much value they are getting for that lower cost. Host Krish Palaniappan spent much of his conversation with Brian Samson pressing on exactly that gap, playing devil’s advocate at nearly every turn, and the exchange produced one of the more rigorous breakdowns of nearshore economics available on any podcast. Krish did not let Brian get away with vague claims about savings; he wanted the actual math.

What emerged is a framework that treats nearshoring less like a discount and more like an arbitrage calculation, one where a company can save 50 percent on cost while absorbing only a 10 to 20 percent dip in output quality, netting a real gain in value rather than just a lower invoice. That distinction, cost savings versus value creation, is the thread running through the entire episode.

Samson has built his career around proving that math out in practice. He has spent 11 years in nearshoring, made more than 500 placements, and built three separate companies to $4M ARR each. He moved to Buenos Aires with two suitcases, grew a software development team there to 80 engineers, and later exited that business. Today he runs Plugg Technologies from Hawaii, placing senior Latin American developers, DevOps engineers, QA specialists, and data engineers with U.S. companies.

The Real Math Behind Nearshoring

Krish Palaniappan pushed Samson to defend nearshoring on grounds other than price, asking directly whether there was any reason to hire nearshore or offshore that had nothing to do with the dollar amount being saved. Samson’s answer reframed the entire conversation around labor arbitrage rather than simple cost cutting. Using Mexico as an example, he walked through the numbers: a U.S. based technical role paying a $150,000 base salary actually costs a company closer to $200,000 once benefits, FICA, and employer taxes are factored in. The equivalent role in Mexico, once local benefits like the aguinaldo (a mandatory 13th month salary) are included, runs closer to $100,000 all in.

That is a 50 percent cost reduction. But Samson was careful to note that quality does not drop by the same percentage. In his experience, the quality gap between a well vetted nearshore hire and a U.S. based one runs closer to 10 to 20 percent, which means the net effect is closer to a 30 percent gain in value once cost and output are weighed together. This is the calculation Samson wants hiring managers to run before they dismiss nearshoring as a race to the bottom on price. It is not about finding the cheapest person available, it is about finding where the value curve actually bends in a company’s favor.

The Cultural Question Most Hiring Managers Get Wrong

Krish Palaniappan raised a pointed objection that many hiring leaders quietly share: if a company already trusts a domestic hire’s resume, LinkedIn history, and legal accountability without a second thought, why should international hiring require extra scrutiny? “I’m not worried that Brian Samson is Brian Samson. I’m not worried that Brian’s resume is any different from what Brian purports that resume to be. I go to LinkedIn’s profile. I know Brian’s been doing this and I trust everything that Brian says,” said Krish Palaniappan, framing the deeper issue as one of unfamiliar geography and legal systems rather than talent quality itself.

Samson’s response separated two distinct kinds of culture that often get conflated. There is the surface level culture of customs and communication style, and then there is what he called startup culture, the shared experience of solving hard problems under real constraints. He argued that the attributes most hiring managers actually want, critical thinking, resourcefulness, grit, and humility, are becoming harder to find in populations that have not had to navigate real adversity. Latin American professionals who have lived through hyperinflation, labor strikes, and menu prices that change so often they are written in chalk develop those traits out of necessity. Samson pointed to the growth of venture capital ecosystems in Argentina, Brazil, and India as evidence that this same startup pressure is now producing a deep bench of talent that has been tested the same way U.S. founders have been tested.

The One Time a Candidate Was Not Who They Said They Were

Krish Palaniappan’s skepticism about international hiring risk was not abstract, and Samson met it with a real story rather than a reassurance. Over five years running Plugg Technologies, there was exactly one instance where the person who showed up for the first day of work did not appear to be the same person who had completed the interview process. “So in other words, Brian, you hired somebody and then the person who showed up to the job was different from the person who actually took the interview initially,” said Krish Palaniappan, confirming the detail before moving on.

Samson’s takeaway was not that international hiring is inherently riskier, but that hiring rigor matters more than geography. Companies that skip background checks, reference calls, and video interviews in a rush to fill a seat are the ones most exposed to this kind of problem, regardless of where the candidate is based. A disciplined process, video verification, reference checks, and a structured interview loop, catches this before it becomes a first day surprise. This is a useful reminder for any company evaluating nearshore staffing partners: the safeguard is not avoiding international talent, it is building a hiring system rigorous enough to trust regardless of where the candidate lives.

AI Is Not Killing Nearshoring, It Is Multiplying Its Value

The most forward looking exchange in the episode centered on whether AI tools make nearshoring less necessary, since companies can now do more with fewer people. Krish Palaniappan pushed this scenario hard, citing a founder who went from 50 employees to eight and asking whether the savings from AI adoption might simply replace the savings companies used to get from hiring abroad.

Samson’s answer was that the two are not competing forces, they compound. A company that combines a nearshore team with AI tooling gets what he called a double bonus arbitrage: the labor cost savings of nearshoring layered on top of the productivity gains from AI, rather than one canceling out the other. He was careful to note that AI is not a U.S. exclusive advantage; nearshore talent is adopting the same tools just as quickly, so the productivity gap does not disappear, it compounds in the buyer’s favor on both sides of the equation.

Why the Engineering Org Chart Is About to Look Different

Both Samson and Krish Palaniappan agreed that the makeup of engineering teams is shifting in ways that are hard to predict from historical hiring templates. Samson argued that mid-level engineering managers, people too senior for day to day coding but not senior enough to operate at an executive level, are increasingly exposed as companies flatten their organizational structures. He pointed to a pattern he first observed at a San Francisco unicorn: engineers overwhelmingly prefer leads who are still writing code themselves, and professionalized management layers that pull people away from hands on work tend not to last.

Krish Palaniappan extended the argument beyond engineering, noting that software developers are far from the only role that could be affected by AI driven efficiency gains. “I don’t know why it’s just software engineers that everyone seems to come after. I think there are a lot of roles that are going to disappear. It’s not just us,” said Krish Palaniappan. Both agreed that the traditional formula of one architect, three developers, one product manager, and one tester is unlikely to hold, and that team composition going forward will need to be built role by role rather than templated from past hires. Samson closed the thread on a striking note about how far this shift has already gone: “You’re building a software company, you’re building software, but you actually don’t have a technical co-founder, which is a statement that you one could not have made a year ago or maybe two years ago,” said Krish Palaniappan, reacting to Samson’s point that AI tools now let non-technical founders get a product to the validation stage before ever hiring an engineer.

How to Get Started

For companies weighing whether and how to bring nearshore talent into their hiring mix, the conversation points to a few concrete next steps.

1. Run the actual arbitrage math before deciding. Compare the fully loaded cost of a domestic hire against the fully loaded cost of a nearshore hire, then weigh the realistic quality gap, not the assumed one, before making a call.

2. Tighten the hiring process rather than avoiding international candidates. Video verification, reference checks, and a structured interview loop reduce risk far more effectively than staying domestic out of caution.

3. Pair nearshore hiring with AI adoption rather than choosing between them. The two produce compounding value when used together, not competing savings.

4. Rebuild team composition role by role. Do not assume the engineering org chart that worked two years ago still applies. Start from the specific problem being solved and staff accordingly.

The Bottom Line

The core insight from this conversation is that nearshoring, done with real rigor, is not a shortcut around quality, it is a way to buy more value for the same dollar. Samson’s own path from a San Francisco talent recruiter to a founder running nearly 100 people across Latin America shows what happens when that math is applied consistently over a decade.

Summary

🌎 Brian’s Background & Business Focus

• Former head of talent in SF tech

• 10+ years operating in Latin America

• Plug Technologies founded in 2022

• Focus: Matching U.S. companies with Latin American tech talent

• Value: Same or similar time zones → better collaboration & cultural proximity

🧠 Offshoring vs Nearshoring vs Onshoring (Key Definitions)

Outsourcing: Contracting work outside your core team

Offshoring: Hiring across oceans (e.g., US → India)

• Lower cost, follow-the-sun model

  Nearshoring: Hiring in nearby countries, same or close time-zone (e.g., US → LATAM)

• Cost savings + real-time collaboration

  Onshoring: Hiring in your country

• Shared culture, fewer risks, highest cost

💸 Labor Arbitrage & Value Equation

• Offshoring/nearshoring isn’t only about cost reduction

• Value focus:

  • Example: $200K US engineer → $100K LATAM engineer

  • ~50% savings with maybe 10–20% difference in quality

  • Net value gain ~30%

💼 Cultural & Skills Considerations

• LATAM talent described as:

  • Resourceful, gritty, clever, hardworking, loyal

• Result of real-world economic pressures & scrappy startup environments

• “Top talent exists everywhere — location is less relevant now”

👀 Trust, Vetting & Hiring Challenges

• Global hiring challenge: fake candidates & misrepresentation

• Rise in impersonation cases with remote interviews

• Solution: rigorous hiring process

  • structured interviews

  • video calls

  • references

  • background checks

🤖 AI’s Impact on Talent Models

• AI lowers cost of building software

• Teams can be smaller & more efficient, wherever they’re located

• Future = nearshoring + AI → double efficiency advantage

• Core leadership team still valuable close-by

• Supplemental talent can be global

🚀 Entrepreneurship in the AI Era

• Lower barriers to start companies than ever

• Offshoring + nearshoring + AI → “multi-order efficiency boosts”

• More global entrepreneurs, less need for huge seed capital

👷 Future of Engineering & Workforces

• Composition of engineering teams will change

• Fewer engineers needed, but higher-quality roles

• Rise of lean teams

• Mid-level managers at risk (trend already visible in Big Tech)

• ICs and senior leaders remain crucial

🎓 Education & Young Talent

• Universities lag behind tech evolution

• Students must self-learn AI and modern tools

• Product-thinking engineers become more valuable

🔮 Predictions on AI & Jobs

• AI won’t replace developers wholesale yet

• But team structure, workflow, and required knowledge will reshape

• “Everyone must re-learn how to build software”

Frequently Asked Questions

What is nearshoring in business terms?

Nearshoring means hiring talent in a nearby country that shares a similar time zone to the hiring company, as opposed to offshoring, which sends work to a distant, often lower cost region regardless of time zone overlap. Brian Samson of Plugg Technologies describes nearshoring for U.S. companies as hiring across Latin America, where teams remain available for real time collaboration during the U.S. workday.

Why do U.S. companies choose Latin America over Asia for nearshoring?

Time zone alignment is the primary reason. Brian Samson explains that Latin American countries fall on U.S. time zones or close to them, enabling same day collaboration on tools like Slack and Jira, whereas offshoring to Asia typically sacrifices that overlap in exchange for deeper cost savings.

What roles can be nearshored to Latin America?

Software developers, DevOps engineers, QA specialists, and data engineers are the roles Brian Samson places most often through Plugg Technologies. He notes that non-core functions like finance and accounting can also be outsourced regardless of location, while core technical roles benefit most from the time zone alignment that nearshoring specifically provides.

How much can a company save by nearshoring instead of hiring domestically?

Brian Samson estimates roughly 50 percent cost savings when nearshoring a technical role to a country like Mexico, once fully loaded U.S. costs like benefits and employer taxes are factored in. He argues the quality difference is much smaller, closer to 10 to 20 percent, which results in a net value gain rather than a simple discount.

Does AI reduce the need for nearshore hiring?

According to Brian Samson, AI does not replace the value of nearshoring, it compounds it. Companies that combine nearshore talent with AI tooling get layered savings, since nearshore teams are adopting the same AI tools as quickly as U.S. based teams, meaning the productivity gains apply on both sides of the equation rather than eliminating the need for nearshore staffing.

What does Plugg Technologies do?

Plugg Technologies is a nearshore staffing company founded by Brian Samson that connects software developers, DevOps engineers, QA specialists, and data engineers across Latin America with U.S. companies. The company has made more than 500 placements over 11 years and is led by Samson and his partner Ruben, both former expats in Latin America. More information is available at plugg.tech.

Brian Samson is the founder of Plugg Technologies and host of The Nearshore Cafe Podcast. This post is based on his appearance on the Snowpal Podcast.

AI + Snowpal API: Reduce Time to Market

AI + Snowpal API: Reduce Time to Market

Podcast

The Post-Vibe-Coding Era: AI Agents, Code Review, and the Future of SaaS — on Apple and Spotify.

Overview

Most “AI is changing engineering” content stays at the level of anecdote. This piece tries to go one layer deeper into four specific claims made in the conversation, each of which has concrete operational implications for engineering teams:

1. Cloud native’s definition is shifting under AI-assisted development,

2. Code review is becoming a two-stage, agent-then-human pipeline,

3. Model selection is a benchmarking problem, not a leaderboard-reading problem, and,

4. Token spend is emerging as a per-developer budget line that companies don’t yet know how to reason about. A closing section covers the SaaS market debate.

1. Cloud native as an operating model, and what AI is doing to it

Chippagiri’s framing is that cloud native was never really defined by its toolchain. Containers and Kubernetes are necessary but not sufficient: “We’re using containers, Kubernetes does not automatically make it like a cloud native system.” A cloud native system additionally has to satisfy elasticity, resilience, and observability requirements, and has to tolerate frequent change without breaking. That’s a design-time property, not a deployment-time one — you can run Kubernetes and still build a brittle, unobservable monolith split into pods.

What’s changed operationally between 2024 and 2026, in his account, is not the definition itself but who is now producing systems that have to meet it. He described developers with no formal coding background building, deploying, and iterating on entire websites without understanding the underlying code. The practical effect: time-to-first-deployment has collapsed toward zero, but the gap between “deployed” and “cloud native” (elastic, observable, resilient) hasn’t closed at the same rate. That gap is where the rest of the conversation lives.

2. The two-agent review pipeline

This is the most concrete technical artifact in the conversation. Chippagiri described a specific pattern his team uses to manage what he calls “review fatigue” — the bottleneck created when AI tools let individual contributors generate far more code than a human reviewer can meaningfully read line-by-line.

The pattern has two stages:

Stage 1 — Agent-to-agent review. One agent (”Agent A”) generates the code. A second, independently prompted agent (”Agent B”) reviews Agent A’s output against a specification: does this code do what it claims to do, and does it match the intended design? Chippagiri: “I have an agent A that writes a whole bunch of code. And now I have my own agent B that reviews what agent A has written. And then you give it a prompt saying, hey, this is what it’s supposed to look like. Does this code basically do what you want it to do?”

Stage 2 — Human gatekeeping. The human reviewer doesn’t re-derive Agent B’s findings from scratch. Instead, they validate Agent B’s comments against the diff: “So the way the human in the loop works is like, hey, at some point there needs to be a human that does the gatekeeping... So Agent A has done this, Agent B has reviewed what it is and then given a list of comments. So let’s see how valid these are.”

The engineering rationale is cognitive-load reduction, not review elimination. A human is still the final gate before production, but the human’s job shifts from generating findings to adjudicating findings an agent already surfaced. Chippagiri reports this pattern being particularly useful on large merge requests, where the volume of changes would otherwise overwhelm a single-pass human review.

Two implementation details worth noting for teams considering this pattern: first, Agent B needs an explicit spec or acceptance criteria to review against — without one, a review agent can only check for internal consistency, not correctness against intent. Second, the pattern doesn’t remove the need for engineers to independently build intuition for AI-generated code. Chippagiri’s advice here is to interrogate the model directly: “If you just ask the model, like, why did you do this, it basically explains to you the entire logic.” He frames this as a skill that compounds with repetition rather than something you either have or don’t: “The only limiting factor is yourself.”

3. Where the PRD goes when PMs can prototype

A secondary but related shift is upstream of the code entirely. Product requirements used to arrive as prose — a PRD document describing what should be built and why. Chippagiri described PMs increasingly using AI tools to produce working mockups instead: actual buttons, actual layout, a clickable approximation of the target UI, before requirements ever reach engineering.

The technical consequence is that the model doing the implementation work now has two inputs instead of one: the PRD (business logic, constraints) and a working prototype (visual/interaction target) that the model can read alongside the existing codebase to propose an integration. Chippagiri describes the resulting cycle as compressing from weeks to days — not because the code got easier to write, but because the ambiguity between “what the PM meant” and “what the PM wants on screen” got resolved before implementation started, removing a round-trip that used to consume much of the cycle time.

4. Model selection as a benchmarking discipline

With model proliferation accelerating, Chippagiri’s approach to selecting a model for a given task is deliberately unglamorous: identify the task, survey what’s already performing well in that category, then benchmark against your own use case rather than trusting general-purpose leaderboards.

He’s specific about specialization: his team leans on Claude Code and Cursor for software generation because those tools are trained heavily on code repositories — “millions of code bases” — rather than general-purpose data. His broader point is that model quality is task-conditional, not a single scalar: “Maybe Gemini may be good at certain things like visual or maybe picture management, but it may not be necessarily the right fit for the software generation.” He extends this to version-level differences within a single model family, noting that some versions outperform others on specific parameters even within the same lineage.

For narrower domains — he uses fintech as an example — his recommended process is: survey vertical AI startups that specialize in the relevant data type (video, image, financial documents, etc.), shortlist candidates based on published performance in that niche, then run internal benchmarks against your own representative tasks before committing. The throughline is that model selection is treated as an empirical, per-team decision, not a one-time platform choice.

5. Token economics: the cost side of the equation nobody’s solved yet

This is the least resolved part of the conversation, and Chippagiri is candid about that. The framing question — raised by Krish, referencing a public comment from Jensen Huang that a developer paid roughly $500K should be expected to consume roughly $2M in tokens — is how to compare token spend against developer time saved.

Chippagiri’s stated formula is simple in structure and hard in practice: compare the dollar value of time saved against the dollar cost of tokens spent. The difficulty, which both speakers acknowledge, is that “time saved” has no stable baseline — task duration estimates vary enormously by engineer seniority, domain familiarity, and team context, so the denominator in that comparison is itself an approximation, not a measured quantity.

On governance, Chippagiri describes token budgeting as moving toward per-developer caps rather than per-team pools, specifically to prevent a small number of high-usage engineers from consuming a shared budget: “I think it has to be managed per developer because that way you can be a little bit more judicious... if you do it as part of a team, then there might be instances where certain people might use most of the tokens.” The evaluative frame companies are converging on, per his account, pairs employee cost (salary, seniority level) against token consumption and expects a visible productivity return: “If you’re going to use this many tokens, show me the amount of productivity that you’ve got.”

The practical implication for engineering leadership: token spend is becoming a per-head metric that sits alongside salary in performance and budget conversations, but the tooling to make that comparison rigorous — reliable baselines for “how long would this have taken without AI assistance” — doesn’t yet exist in a standardized form.

6. Is the SaaS category structurally impaired?

The conversation closes on a market question: Krish notes that companies like Atlassian and Workday have lost significant market cap over roughly two years, against a backdrop of capital flowing hard into AI infrastructure and semiconductor names. Is this evidence that SaaS as a category is being disintermediated by AI-native, wipe-coded alternatives?

Chippagiri’s answer separates cyclical capital rotation from structural threat. On rotation, his point is that capital simply follows whatever sector is currently hottest — “there’s money always moves from what is hot right now” — and today that happens to be AI, with no guarantee it stays that way. On structural threat, his position is that the “SaaS apocalypse” narrative is overstated because SaaS value isn’t primarily code: “SaaS is not just code. It’s also years and years worth of domain knowledge, years and years worth of customization... there’s compliance, there’s governance, there’s regulatory requirements.” His specific technical claim is about scaling difficulty: a small tool can be wipe-coded and will work fine for five or six users, but the gap between that and a product serving millions of users under compliance and governance constraints is where SaaS incumbents retain structural advantage.

Takeaway

The pattern across all four technical threads is consistent: AI tooling has compressed the generation step of software work — code, prototypes, even initial review passes — much faster than it has compressed the judgment step. Review still needs a human gate. Model selection still needs empirical benchmarking per use case. Token spend still needs a cost-benefit framework that doesn’t fully exist yet. And SaaS products still need the accumulated domain, compliance, and scaling expertise that a fast prototype doesn’t carry. The engineering organizations adapting fastest, per this conversation, aren’t the ones generating the most code — they’re the ones building the review, evaluation, and governance layers around that generation as deliberately as they used to build the code itself.

┌───────────────────────────────────────────────────────────────────────────┐
│              SNOWPAL PODCAST — Krish Palaniappan × Srinivas Chippagiri    │
│                  "AI, Cloud Native & The Future of Engineering"           │
└───────────────────────────────────────────────────────────────────────────┘

  CLOUD NATIVE, REDEFINED
  ┌────────────────────────────┐
  │ Containers/K8s ≠ cloud     │
  │ native. Needs: elasticity, │
  │ resilience, observability  │
  └──────────────┬─────────────┘
                 │
                 ▼
  AI CHANGES WHO CAN BUILD
  ┌────────────────────────────┐
  │ Non-coders ship prototypes │
  │  & even production apps    │──────┐
  └──────────────┬─────────────┘      │
                 │                    │ but...
                 ▼                    ▼
  VIBE CODING RISK              PRD → PROTOTYPE
  ┌──────────────────────┐      ┌───────────────────────┐
  │ Understanding code =  │      │ PMs mock up UI with AI │
  │ proportional to how   │      │ before writing PRDs;   │
  │ well you can debug it │      │ dev cycles: weeks→days │
  └──────────┬────────────┘      └───────────────────────┘
             │
             ▼
  TWO-STAGE CODE REVIEW PIPELINE
  ┌─────────────┐      ┌─────────────┐      ┌───────────────┐
  │  Agent A     │ ───▶ │  Agent B     │ ───▶ │  Human         │
  │  writes code │      │ reviews vs.  │      │  gatekeeper    │
  │              │      │  spec        │      │  validates     │
  └─────────────┘      └─────────────┘      └───────────────┘
             │
             ▼
  WHY ENGINEERS STILL MATTER
  ┌────────────────────────────┐
  │ Coding = 1 pillar of        │
  │ engineering. Domain/tribal  │
  │ knowledge ≠ modelable       │
  └──────────────┬─────────────┘
                 │
                 ▼
  MODEL SELECTION            TOKEN ECONOMICS
  ┌────────────────────┐      ┌────────────────────────────┐
  │ Task → survey →    │      │ $ tokens vs. $ time saved  │
  │ benchmark yourself │      │ Caps set PER DEVELOPER,    │
  │ (no single winner) │      │ not per team               │
  └────────────────────┘      └────────────────────────────┘
                 │
                 ▼
  SaaS: APOCALYPSE OR OVERBLOWN?
  ┌─────────────────────────────────────────────┐
  │ Capital rotation (SaaS → AI) ≠ structural   │
  │ decline. SaaS moat = domain + compliance +  │
  │ governance + scale, not just code           │
  └──────────────────┬──────────────────────────┘
                     │
                     ▼
  CLOSING TAKE
  ┌─────────────────────────────────────────────┐
  │ Generation got fast. Judgment didn't.       │
  │ The winners build review, evaluation & cost │
  │ governance as deliberately as they once     │
  │ built the code itself.                      │
  └─────────────────────────────────────────────┘

There is a meaningful difference between pasting a problem into ChatGPT and deploying an AI system that autonomously orchestrates multi-step workflows across a regulated enterprise. Karl has spent the last several years working in that gap — building what he calls “AI coworkers” for wealth management firms and manufacturers. This article unpacks the architectural decisions, engineering philosophy, and organizational implications behind that work.

AI + Snowpal API: Reduce Time to Market

Podcast

Beyond RAG: Building Production-Grade AI Coworkers for the Enterprise — on Apple and Spotify.

Summary

1. The Problem With Vanilla RAG — why knowledge graphs are necessary beyond hybrid BM25+vector retrieval

2. The Agentic Harness — multi-model routing, observability, and the two-tier feedback loop (DeepLens + aggregate optimization)

3. The Tech Stack — Python, LangChain/LangGraph/LangSmith, React, database-agnostic deployment, and in-client cloud architecture

4. Two Case Studies — wealth management meeting prep (8,000 hours eliminated) and the field service diagnostic reporting app

5. Human-AI Engineering Teams — the 80/20 assembly line, TDD enforced at the AI layer, and developers as AI coworker managers

6. Interfaces for Human and Agent Consumers — dynamic dashboard generation and why Markdown outperforms JSON for agent-to-agent handoffs

7. The Broader Shift — what changes (mid-management, SaaS economics, the value of specification over implementation) and what doesn’t (core engineering discipline)

The Problem With Vanilla RAG

Retrieval-Augmented Generation is the obvious starting point for any system that needs to answer questions grounded in proprietary data. Hybrid RAG — combining dense semantic search with sparse BM25 indexing — improves recall over pure vector similarity. But Simon argues that even hybrid RAG is insufficient for enterprise contexts, because it lacks the domain structure to know which retrieved chunks are actually relevant to the question at hand.

Consider a wealth management firm preparing for a quarterly client review. Relevant information is scattered across custodial platforms, risk management systems, retirement and estate planning tools, tax software, CRM records, email, calendar, and document storage. A naive RAG query returns semantically similar chunks, but it has no way to understand the relational context: that a particular estate plan is tied to a specific client’s risk tolerance, which is in turn constrained by a life event recorded in the CRM.

Subatomic’s answer is what Simon calls “RAG plus”: a knowledge graph that encodes the domain model — entities, relationships, and their interdependencies — and then uses that graph to bound and contextualize retrieval. When a query comes in, it is not simply sent to a vector index. Instead, the knowledge graph provides a contextual boundary that filters and ranks retrieved chunks according to their position in the domain model. The result is what Simon describes as “contextually guardrailed” retrieval — semantically relevant and domain-coherent.

Building the knowledge graph correctly is non-trivial. It requires capturing how services interconnect, how client profiles relate to financial instruments, and how different regulatory and planning concerns interact. “We handle the tricky,” Simon says. “We handle the complex.”

The Agentic Harness: Why Prompting Alone Falls Short

A common misconception Simon encounters is that a well-crafted prompt to a capable foundation model is functionally equivalent to a purpose-built agentic system. It is not — and the gap becomes obvious at scale.

Even the best publicly benchmarked models achieve accuracy rates well below the 90th percentile on complex, multi-step tasks when given only a single-pass prompt. The core issue is that a prompt is stateless and monolithic. It cannot dynamically branch on intermediate findings, consult external knowledge mid-execution, or route sub-tasks to specialized models.

An agentic harness solves these problems by decomposing complex workflows into discrete steps, each of which can independently reason, retrieve, and act. Within any given step, the harness can branch based on intermediate outputs — routing a technical diagnostic question differently from a billing inquiry, for example. This structure also enables:

Multi-model routing. Subatomic deploys multiple models simultaneously — both commercial (OpenAI, Anthropic) and open-source — and assigns tasks to models based on fit. A large frontier model handles nuanced reasoning; a fine-tuned smaller model handles a narrow classification step faster and more cheaply. This is not just cost optimization; smaller specialist models often outperform larger generalists on tasks they were trained for.

Observability as a first-class citizen. Subatomic uses LangSmith for baseline tracing and augments it with extended audit logs that surface the full chain of reasoning to clients. Every execution records which workflow steps were invoked, what reasoning was applied, and what intermediate answers were produced. This matters in regulated industries where you cannot simply say “the AI decided.”

Continuous optimization. Simon describes a two-tier feedback loop. At the request level, a dedicated AI coworker called DeepLens evaluates the execution in real time, checks it against expected reasoning patterns, and self-corrects before returning a final answer. At the aggregate level, patterns across executions are analyzed for accuracy, faithfulness, consistency, and cost anomalies — and the knowledge graph and retrieval configuration are updated accordingly.

The Tech Stack

Subatomic’s stack reflects a bias toward flexibility and interoperability over vertical lock-in.

Languages and frameworks. Python is the primary language, chosen in part because it is common enough that clients who want a co-management support model can participate. LangChain is the primary orchestration framework; LangGraph handles graph-based agent topology; LangSmith provides tracing.

Frontend. React components, with the capability to dynamically generate UI elements at runtime based on the nature of a request — not just serve a static dashboard.

Databases. Rather than imposing a fixed data store, Subatomic adapts to whatever the client already operates: Postgres by default, but also Snowflake, Databricks, SQL Server, Oracle, and others. This is less about maintaining a library of pre-built connectors and more about code generation: Subatomic’s AI coworker engineers can produce dialect-specific code for a given target system rapidly, including transformations between structural paradigms (relational, key-value, graph) when a client is migrating or consolidating.

Deployment. Subatomic is not a SaaS product. It deploys into the client’s own cloud account (AWS, Azure, GCP) or on-premises, ensuring that client data never leaves their security perimeter. Security and auditability are designed in from the start, not bolted on.

Architecture in Practice: Two Case Studies

Wealth Management: Client Meeting Preparation

The flagship use case eliminates the manual labor of aggregating information before a client meeting. An advisor’s relevant data — portfolio positions, risk profile, tax exposure, estate planning status, recent correspondence, CRM notes — is scattered across at least six distinct systems. Previously, assembling a 360-degree view required hours of manual extraction and synthesis.

With the Subatomic system in place, the AI coworker traverses the knowledge graph to identify all entities related to the client, retrieves relevant documents and structured records via hybrid RAG, and produces a synthesized briefing scoped to the meeting’s agenda. The system eliminated approximately 8,000 hours of labor annually across one firm’s advisor team.

Field Service: Automated Diagnostic Reports

A high-end commercial oven manufacturer needed to standardize the quality of field service reports. Technicians would spend multiple days on-site diagnosing complex failures; the reports they produced varied significantly in quality and structure.

Subatomic built a mobile application (tablet and phone form factors) that guides technicians through a structured diagnostic workflow. The app collects text, photos, and video as a technician progresses through diagnosis steps. Once all data is captured, an agentic system — pulling in the relevant maintenance documentation via hybrid RAG, bounded by the product’s knowledge graph — synthesizes a formatted report that reflects the company’s preferred documentation practices.

What makes this more than a form-filling tool is the dynamic branching. The workflow adapts based on the category and complexity of the fault being diagnosed, surfacing different sub-procedures and reference documents depending on intermediate findings.

Human-AI Engineering Teams

Subatomic operates with 13 human engineers and over 100 AI coworkers. The ratio was not always this way; it inverted over the past year. This inversion has specific implications for how the team is structured and how software gets built.

The 80/20 assembly line. Subatomic has two internal AI coworker platforms: Nexus for data engineering tasks, and Nucleus for workflow orchestration. Together, they generate approximately 80% of the codebase for a given client engagement. Human engineers handle the final 20% — the layer that is specific to the client’s operating procedures, cognitive patterns, and regulatory context. Below that custom layer are reusable domain modules (industry-standard patterns and entity models) that are shared across engagements, though never identical codebases between clients.

Test-driven development enforced at the AI layer. Simon is emphatic about test-driven coding. Functional and technical test conditions are specified before any code is generated, and the AI coworkers are required to produce code that satisfies those conditions. This is not just a quality mechanism — it is an accountability mechanism. When testing is separated into a distinct role, he argues, it diffuses responsibility. When the code-generating system is also responsible for passing the tests it was given, accountability stays in one place.

Developers as AI coworker managers. The practical role of a human engineer at Subatomic has shifted from writing code to managing the AI coworkers that write code — reviewing output, specifying constraints, catching edge cases that automated generation misses. Software design patterns and data engineering patterns still matter; they are what make an engineer capable of evaluating whether the AI’s output is durable for production conditions. Vibe-coded output, in Simon’s assessment, almost always lacks the security hardening and edge-case handling required for real production environments.

Interfaces for Human and Agent Consumers

The field service application raised an important design question: should the interface be a structured form or a conversational interface? Subatomic initially built headless (chat-only) interfaces and found strong adoption among technically sophisticated users. When clients requested dashboards, the team did not simply add static charts — they built dynamic visualization generation. An advisor can ask a natural-language question and receive both a synthesized answer and an auto-generated dashboard that surfaces the key metrics supporting that answer.

For agent-to-agent communication, Simon points to a structural shift away from JSON as the interchange format toward Markdown. Large language models synthesize Markdown more reliably than JSON when passing context between agents; JSON-encoded intermediate state produces less consistent output on the receiving end. This has practical implications for how agentic pipelines are designed: when agents need to hand off context to one another — whether within the same system or across organizational boundaries in something like a supply chain — Markdown-structured summaries outperform raw structured data as the information carrier.

Role-based access control applies equally to human and agent callers. A registry of accessible tools and functions is maintained per caller identity, regardless of whether that caller is a human in Slack or an upstream agent.

The Broader Shift: What Changes and What Does Not

The fundamental practices of software engineering — design patterns, data modeling, security architecture, observability — have not changed. What has changed is the ratio of human effort required to produce a working implementation. The “hello world to production” journey is dramatically shorter when 80% of the scaffolding is generated. This does not mean the scaffolding does not need to be reviewed; it means the review is more valuable than the generation.

Mid-management may be disproportionately affected. AI systems that unify information across organizational silos — eliminating the need to escalate requests through multiple layers to get a cross-functional answer — reduce the coordination function that mid-management has historically provided. Simon estimates 80% of director and senior-manager level roles could be affected by 2028.

The SaaS model faces structural pressure. If an organization can instruct an AI coworker to build a CRM tailored to its own workflows — rather than licensing a general-purpose one and customizing around its constraints — the economic case for many vertical SaaS products weakens. Subatomic itself has replaced its own CRM with an internally generated alternative.

The most durable engineering skill, in this view, is not the ability to write code. It is the ability to specify what correct code looks like — to define the test conditions, the architectural constraints, and the security requirements that a generated implementation must satisfy. That specification skill requires deep domain and systems knowledge. It is also the hardest to automate.

FAQ

Architecture & Retrieval

Q: What is “RAG plus” and how does it differ from standard RAG?

Standard RAG retrieves documents by semantic similarity. Hybrid RAG adds sparse keyword indexing (BM25) to improve recall. “RAG plus” goes a step further by layering a knowledge graph on top of retrieval — the graph encodes domain entities and their relationships, and retrieval is bounded within that contextual structure. This means the system does not just find semantically similar chunks; it finds chunks that are coherent within the domain model relevant to the query.

Q: Why is a knowledge graph necessary? Can’t a well-structured vector index do the same job?

A vector index captures semantic proximity, not relational structure. In a domain like wealth management, the relevance of a document depends on how its subject relates to other entities — a tax document is relevant to a client meeting only if it is connected to that specific client’s profile and current planning objectives. A knowledge graph makes those connections explicit and traversable. Without it, retrieval is context-blind.

Q: What interchange format works best for agent-to-agent communication?

Markdown. JSON was an earlier default for passing state between agents, but large language models produce less consistent output when synthesizing from JSON-encoded context. Markdown-structured summaries yield more reliable downstream reasoning, whether the receiving agent is internal to the same pipeline or external across an organizational boundary.

The Agentic Harness

Q: Why not just use a foundation model directly with a detailed prompt?

A single-pass prompt is stateless and monolithic. Even well-designed prompts to top-tier models achieve accuracy below 90% on complex, multi-step tasks. An agentic harness decomposes the problem into discrete steps, enables dynamic branching on intermediate results, consults external knowledge mid-execution, and routes sub-tasks to purpose-fit models. The compounding effect across many steps makes the difference between a prototype and a production system.

Q: How does multi-model routing work in practice?

Tasks are evaluated at runtime and assigned to the model best suited for that specific sub-task — a large frontier model for nuanced reasoning, a smaller fine-tuned model for a narrow classification step. The goal is both cost efficiency and accuracy: smaller specialist models often outperform larger generalists on tasks they were trained for. Sending every request to the largest available model is both wasteful and sometimes less accurate.

Q: What does observability look like inside an agentic system?

At the request level, every execution records which workflow steps were invoked, what reasoning was applied, and what intermediate answers were produced before the final output. A dedicated evaluation layer checks the execution against expected reasoning patterns in real time and self-corrects before returning a result. At the aggregate level, patterns across executions are analyzed for accuracy, faithfulness, consistency, cost, and standardization — and the system configuration is updated accordingly.

Q: How do you prevent an agentic system from hallucinating or going off-rails?

Several mechanisms work together: the knowledge graph bounds retrieval to contextually relevant information; workflow steps are pre-defined with explicit logic branches rather than open-ended generation; test conditions are specified upfront and the system must satisfy them; and a real-time evaluation layer audits the execution chain before output is returned. Security and observability are not add-ons — they are designed into the harness from the start.

Deployment & Integration

Q: Is this a SaaS product that customers sign up for?

No. The system deploys into the client’s own cloud environment (AWS, Azure, GCP) or on-premises. The client is the tenant of the account. This ensures data never leaves the client’s security perimeter and allows the deployment to conform to the client’s existing security controls rather than requiring them to adapt to a third-party SaaS boundary.

Q: How does the system handle clients with different database infrastructure?

Rather than requiring a specific database, the system generates dialect-specific code for the target data store — Postgres, Snowflake, Databricks, SQL Server, Oracle, and others. When a client is migrating between platforms (e.g., Redshift to Snowflake), the system can convert the relevant query logic with minimal impact. When the underlying data structure changes (e.g., relational to key-value), adapter code handles the transformation. The guiding principle is minimum disruption to existing architecture.

Q: Can the system integrate with existing communication tools like Slack or Teams?

Yes. A “chief of staff” layer acts as the coordination point for all AI coworker teams and is accessible from standard communication channels — Slack, Teams, email, SMS — in addition to a dedicated UI. This broadens adoption because users can interact with the system wherever they already work, without context switching into a separate application.

Engineering Teams & Development Practices

Q: Do you still need software engineers if AI generates 80% of the code?

Yes, and for a specific reason: the value of an engineer has shifted from writing code to specifying what correct code looks like. Defining test conditions, architectural constraints, security requirements, and edge-case behavior requires deep systems knowledge. Vibe-coded output — generated without those constraints — is consistently more fragile in production: it misses security hardening, fails on edge cases, and is difficult to audit. Someone with engineering discipline needs to own the final 20% and verify the 80%.

Q: How has test-driven development changed with AI code generation?

Test conditions are now specified as inputs to the AI coworker before code generation begins, not written after the fact. Functional requirements come from business stakeholders; technical requirements (performance, security, edge cases) come from engineers. Both feed into the planning and design phase before any code is produced. This approach preserves accountability: the system that generates the code is also responsible for satisfying the tests, rather than diffusing that responsibility across separate roles.

Q: What is the practical role of a human engineer on an AI-augmented team?

Human engineers function as managers of AI coworker teams. They specify what needs to be built, define the guardrails and test conditions, review generated output for durability and correctness, and handle the client-specific customization layer that requires judgment about that organization’s particular workflows and constraints. The core software design and data engineering knowledge is what makes them capable of doing that review effectively.

Q: Is vibe coding viable for production systems?

For non-critical applications where downtime is tolerable and accuracy requirements are loose, vibe coding can reach a functional state quickly. For systems operating in regulated industries, handling financial or medical data, or requiring consistent behavior across many users, it is not sufficient on its own. The generated code needs review by someone who can evaluate security posture, architectural soundness, and coverage of production edge cases — and who can be accountable to clients when something breaks.

Interfaces & User Experience

Q: Should enterprise AI systems use chat interfaces or traditional dashboards?

Both, dynamically. A chat-first interface enables natural-language access and improves adoption because users can interact without learning a new UI. But when a response warrants visualization — key metrics, comparative data, trend analysis — the system should auto-generate the appropriate dashboard for that specific query rather than serving a static pre-built view. Static dashboards answer the questions you anticipated; dynamic generation answers the ones you did not.

Q: How should UX be designed for systems that serve both humans and agents?

The interface layer needs to produce responses appropriate to the consuming audience. For human users: contextually relevant answers with dynamic visualization where useful. For agent consumers: Markdown-structured outputs that downstream models can synthesize reliably. Role-based access control applies equally to both — a registry of accessible tools and functions governs what any given caller, human or agent, is permitted to invoke.

Organizational Impact

Q: Which roles are most affected as AI takes on more knowledge work?

Engineering is the most visible impact so far, with AI systems generating the majority of code and reducing the human headcount needed for a given output level. Mid-management may be equally or more affected: AI systems that unify information across organizational silos perform the coordination function that middle management has historically provided, reducing the need to escalate requests through multiple layers to get a cross-functional answer.

Q: What happens to vertical SaaS products as AI coworkers become more capable?

The economic case for many vertical SaaS products weakens when an organization can instruct an AI coworker to build a fit-for-purpose tool tailored to its own workflows — without paying per-seat licensing fees or working around a vendor’s constraints. Organizations that are AI-first are already building internal replacements for CRM, reporting, and workflow tools rather than licensing external products. This trend is likely to accelerate as AI coworker code generation becomes more reliable.

Q: What is the most durable skill for engineers going forward?

The ability to specify what correct behavior looks like: defining test conditions, architectural requirements, security posture, and the edge cases a system must handle. This is harder to automate than code generation because it requires understanding the domain, the failure modes, and the accountability structure of the system being built. Engineers who develop strong specification skills will function effectively as the managers and reviewers of AI-generated code regardless of how capable automated generation becomes.

Podcast

Your Website Is Invisible to AI: Here’s How to Fix It — on Apple and Spotify.

The SEO Crisis No One Saw Coming

For decades, the rules of search engine optimization were clear: rank high on Google, drive traffic, convert visitors. That playbook is now being rewritten at speed.

According to Frank, a digital marketing expert and founder of LLM Scout, his agency is seeing average traffic drops of 30–35% year over year across clients — and some are experiencing drops as steep as 80%. The culprit isn’t a Google algorithm update. It’s the rise of AI.

“Google and LLMs — ChatGPT, Claude, and others — they tend now to reply directly to the user,” Frank explains. “So there is no reason for people to go and browse websites. For my clients, that’s a big problem.”

Combined with stricter GDPR enforcement in Europe, which requires explicit user consent before analytics fires, marketers are flying increasingly blind. But the story isn’t as bleak as those numbers suggest.

Is SEO Dead? Not Exactly — But It’s Transforming

Despite falling click-through rates, SEO remains foundational — because LLMs still rely on it.

Frank points to a striking statistic: roughly 18% of Google’s traffic today comes from LLM bots. When you ask ChatGPT or Claude a question they can’t answer from training data, they perform live Google searches to gather information. They break your prompt into multiple search queries — a process called “query fan-out” — then crawl the top results in real time to synthesize an answer.

“If you’re still number one in Google, the LLM will recommend you,” Frank says. “The user isn’t clicking the link, but the company is still being discovered.”

The shift, then, isn’t from SEO to something else. It’s from SEO to AEO — Answer Engine Optimization — a discipline focused on making your content readable, trustworthy, and accessible not just to humans, but to AI agents acting on their behalf.

Introducing the Third Web: Markdown Pages for AI Crawlers

One of the most practical strategies Frank recommends is creating a markdown (.md) version of your key web pages alongside the standard HTML version.

Here’s the problem markdown solves: when an LLM crawls your site in real time, it only processes a limited amount of content — approximately the first 100 kilobytes of a page. A typical HTML page is bloated with JavaScript calls, CSS, navigation menus, footers, image tags, third-party scripts, and other “noise” that has nothing to do with the actual content. By the time all that noise is cleared, the meaningful content may never make it into the AI’s context window.

Markdown strips all of that away. It retains only the essential structure — headings (H1, H2, H3), bold text, links, and tables — in a lightweight format that LLMs are deeply familiar with, since most of them were trained on markdown-rich datasets.

How to Implement Markdown Pages

The implementation is simpler than it sounds. For each important page, you:

1. Create a parallel .md file at a predictable URL (e.g., /blog/article-name.md)

2. Add a single directive in your HTML <head> tag:

<link rel="alternate" type="text/markdown" href="/blog/article-name.md">

This tells AI crawlers that a cleaner, machine-readable version of the page exists. The HTML page continues serving human visitors and Google’s traditional crawler without any changes.

Frank’s client at elsewhen.com already has this in production. You can verify it by taking any blog post URL, removing the trailing slash, and appending .md — a stripped-down, content-only version of the article appears instantly.

An Important Caution on Content Parity

Frank flags a critical risk: the markdown version must be substantively identical to the HTML version. Search engines like Google will screenshot your HTML page and compare it to what they can scrape. If the two versions differ meaningfully, you risk a cloaking penalty — the same kind applied to sites that historically hid white text on white backgrounds to game keyword rankings.

Agent-Centric Design: Rethinking How Websites Are Built

Markdown pages address how AI crawls your content. But there’s a second, equally important challenge: how AI agents interact with your pages when they’re taking actions on a user’s behalf.

When a user instructs an agent to “find me a course provider in this space,” the agent doesn’t read your HTML. It visually “sees” your page — essentially taking a screenshot and interpreting what’s there. This is where most modern websites silently fail.

Frank describes a client whose course catalog page had 80% of its content hidden behind tabs. A human visitor instinctively clicks the tabs. An AI agent sees a screenshot, identifies only what’s visually open, and reports back to the user as if the rest doesn’t exist. Entire product lines become invisible.

“We need to have this in mind when designing,” Frank explains. “If I screenshot this page and send it to someone, would they be able to understand that there is a button here, that they need to press something to watch a video?”

Design Principles for Agent Accessibility

The shift Frank advocates isn’t a complete redesign — it’s a new lens applied to existing design decisions:

Avoid hiding content behind interactive elements. Tabs, carousels, accordions, and modals are human-friendly but agent-hostile. If a piece of content matters, make it visible without requiring a click.

Use high contrast and clear visual hierarchy. Agents interpret pages visually. Background images underneath text, low-contrast buttons, and decorative styling can obscure meaning. Black text on white backgrounds, with clear structural hierarchy, performs best.

Redesign mega menus for dual audiences. Interestingly, the mega menu — once dismissed as dated UX — is making a comeback. Frank notes that well-structured mega menus give agents fast access to a site’s most important content areas without requiring deep navigation. EY Parthenon’s site is cited as an example: services and subsections laid out clearly, accessible in one visual sweep.

Carousels are a liability. A carousel only ever shows one item at a time. An agent seeing a screenshot sees one item. Everything else on those slides, for all practical purposes, does not exist.

JSON-LD and Schema Markup: Speaking the Machine’s Language

Long before AI agents arrived, SEOs were enriching web pages with structured data using the schema.org vocabulary and JSON-LD (JavaScript Object Notation for Linked Data). Now, that practice is more valuable than ever.

Schema markup allows you to define entities — companies, products, events, people, reviews, courses, FAQs — in a standardized format that machines parse directly, without hunting through prose for the information. Instead of an AI agent trying to find your phone number or office address buried somewhere in paragraph text, you declare it explicitly:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company",
  "telephone": "+1-800-000-0000",
  "address": { ... }
}

Frank explains that a modern page might carry multiple overlapping schema types: an event, a product listing, an FAQ section, a course, and company information — all described in structured JSON alongside the visual HTML, all invisible to the reader, all immediately legible to an AI.

Google Search Console now surfaces errors in your rich metadata — missing required fields, type mismatches, formatting issues — making it easier to audit and maintain this layer of your site.

LLM.txt: The AI-Native Sitemap

Traditional XML sitemaps tell crawlers what pages exist and when they were last updated. LLM.txt — a newer convention Frank describes — takes a different approach. Rather than listing URLs, it explains how a website is structured in plain language.

An LLM.txt file might say: “This is a B2B consulting firm. Service pages live under /services. New blog content appears at /blog/[slug]. All product pages follow /products/[category]/[product-name].”

It’s less a directory and more a set of orientation instructions — the kind you might give a new employee on their first day.

The adoption of LLM.txt is still uneven. Anthropic has pushed for it; OpenAI has not committed. Frank acknowledges that in practice, most LLMs appear to rely primarily on what’s on the page itself rather than reading either sitemaps or LLM.txt. But the emerging consensus among AEO practitioners is to implement it anyway — the cost is minimal and the potential upside is real.

Citations: The New Backlinks

In traditional SEO, authority was built through backlinks — other websites linking to yours. In the AI-discovery era, the equivalent is citations: your brand name appearing on other credible platforms, even without a link.

LLMs are trained on massive corpora of online text, and sites with high human-generated authority — Reddit, LinkedIn, trusted review platforms — carry disproportionate weight.

“There was a rush on getting your name on Reddit,” Frank recalls. “People found that LLMs loved Reddit and LinkedIn because they have strong spam policies and self-moderating communities. It was seen as human opinion.”

The predictable result followed: marketers flooded those platforms with AI-generated content, platforms adapted their moderation, and the SEO lift faded. But the underlying dynamic remains: authentic presence on authoritative third-party platforms signals trustworthiness to AI systems evaluating which sources to cite.

The lesson isn’t to game Reddit. It’s to build genuine presence where humans actually discuss your industry — because that’s still where AI goes to learn what’s credible.

The Bigger Shift: From Websites to APIs and MCPs

Beneath all the tactical optimizations lies a more fundamental transformation. As Frank and Krish explore in their conversation, the future of software distribution may not be websites or apps at all — it may be APIs and Model Context Protocols (MCPs).

Platforms like Claude’s Cowork already demonstrate the pattern: rather than switching between a dozen separate applications, users interact with one AI interface that connects to all their tools via connectors. Salesforce, HubSpot, Slack — their data and functionality become accessible through a single, personalized layer.

In this world, having a beautiful website matters less than having a well-documented, accessible API. The agent doesn’t visit your homepage. It calls your endpoint.

Frank’s own roadmap reflects this: “My next step is to create an MCP server so that becomes accessible to other tools. You tell the other tools: we exist, this is how you authenticate, this is what you can do. People use our services using other services seamlessly — without even knowing they’re using us.”

Krish echoes this at Snowpal: building an MCP server so AI agents across industries can consume their APIs generically, without needing to know the specific endpoints, with industry-specific sample agents demonstrating the integration model.

AI + Snowpal API: Reduce Time to Market

The Economic Undercurrent: What AI Is Doing to Jobs

No discussion of AI optimization is complete without confronting its broader consequences. Frank speaks plainly about the UK’s youth unemployment — the highest rate for under-25s in over a decade — and links it directly to AI displacing entry-level roles.

“Junior engineers, junior lawyers — that first job, second job — I think those have completely been replaced by AI,” he says. “The problem is those people are not going to climb the ladder, which means eventually there will be no mid-level, no senior. There will be a gap.”

Both Frank and Krish describe an irony shared by many in technology: the tools that increase individual productivity also compress the on-ramps through which expertise is built. Senior developers still manage and review. But without juniors learning by doing, who becomes senior?

Frank’s advice, when pressed, circles back to something almost old-fashioned: find what you genuinely love and pursue it with adaptability as your core skill. “If you have a passion for something, you will make it happen. It won’t become a job you do for money — it becomes your identity.”

How Few People Are Actually Building With AI

Perhaps the most grounding data point in the conversation comes from a graphic Krish shares — sourced, Frank believes, from Diary of a CEO — breaking down global AI adoption:

• 84% of the world population has never used AI

• 16% use a free AI chatbot

• 0.3% pay for a subscription

• 0.04% are actively building with AI

At 8.1 billion people, that 0.04% represents roughly 3.2 million builders. For anyone steeped in the AI conversation — reading newsletters, attending podcasts, refreshing LinkedIn — that number is a useful corrective. The urgency feels total because of algorithmic echo chambers. The reality is that the overwhelming majority of the world hasn’t yet clicked “sign up.”

“I’ve been living in AI anxiety,” Frank admits. “As soon as I go to LinkedIn, everything is about AI. I’m constantly bombarded. But then that graph came along and I thought — I need to breathe.”

The Mechanics of AI Crawling and Query Fan-Out

When a user submits a prompt to an LLM like ChatGPT or Claude, the model doesn’t perform a single search — it decomposes the query into multiple targeted sub-queries, a process called query fan-out. Each sub-query hits a search engine independently, returning a set of ranked URLs. The agent then crawls those pages in real time, parsing the raw HTML to extract relevant content. Because most LLMs cap their page ingestion at roughly the first 100 kilobytes, any content buried beneath heavy JavaScript bundles, third-party script calls, and navigation boilerplate may never enter the model’s context window at all. This is why rendering order in the DOM matters: content that appears early in the HTML source has a structurally higher probability of being ingested than content loaded dynamically via JavaScript after the initial parse.

Structured Data and the JSON-LD Signal Layer

Beneath every well-optimized page lies a machine-readable signal layer built on JSON-LD and the schema.org vocabulary. Unlike prose content, which requires natural language processing to extract entities and relationships, JSON-LD declares them explicitly — a product’s price, an organization’s phone number, an event’s start time — in a standardized format that search engines and AI crawlers can parse deterministically. Modern pages often carry multiple overlapping schema types simultaneously: an Organization block in the site header, a Course or Product block in the body, an FAQPage block in the footer. Each additional schema type expands the surface area of structured facts an AI can confidently extract without inference, reducing hallucination risk and increasing the likelihood that your entity is accurately represented when an LLM synthesizes an answer citing your content.

Key Takeaways for Marketers and Builders

If you’re managing a website or building a digital product in 2025, here are the actionable priorities that emerge from this conversation:

Audit your pages for agent accessibility. Take a screenshot of each important page and ask: could an AI agent understand what’s on this page and what actions are available? If the answer involves clicking tabs or swiping carousels, you have work to do.

Add markdown versions of your highest-value content pages. Use the <link rel="alternative" type="text/markdown"> directive to point crawlers to a clean, noise-free version. Keep the content identical to the HTML version.

Implement or expand JSON-LD schema markup. Every entity type your pages represent — company, product, event, FAQ, course, review — should have corresponding structured data. Audit using Google Search Console’s rich results report.

Write an LLM.txt file. Explain your site’s structure in plain language. It costs almost nothing and may provide meaningful upside as LLM adoption of the standard grows.

Build for citations, not just backlinks. Authentic presence on credible third-party platforms still matters. Focus on genuine value — useful content, honest engagement — rather than volume plays that platforms will quickly detect and discount.

Start thinking in APIs. If you’re building anything new, design it to be consumed by agents, not just browsers. An MCP server or well-documented REST API may ultimately drive more distribution than a polished homepage.

FAQ: Optimizing Your Website for AI Agents

Q: Is SEO dead now that AI answers questions directly?

No — but it’s transforming. LLMs still rely on search engines to find information. Roughly 18% of Google’s traffic today comes from AI bots performing real-time searches on behalf of users. If you rank well on Google, AI is still likely to discover and cite you. The difference is that users no longer click through to your site — the AI summarizes the answer for them. SEO remains the foundation; Answer Engine Optimization (AEO) is the layer you now need to build on top of it.

Q: What is Answer Engine Optimization (AEO)?

AEO is the practice of optimizing your website so that AI systems — ChatGPT, Claude, Gemini, and the agents they power — can find, understand, and accurately represent your content. Where traditional SEO focused on ranking signals for human searchers, AEO focuses on machine readability, structured data, agent accessibility, and authoritative citations across the web.

Q: How much traffic are websites actually losing to AI?

On average, sites are seeing traffic drops of 30–35% year over year. Some are experiencing drops as high as 80%, particularly in Europe where GDPR consent requirements have further reduced trackable traffic. The cause isn’t purely AI — privacy regulations are compounding the problem — but AI-generated answers replacing click-throughs is the dominant factor.

Q: What is a markdown page and why do I need one?

A markdown (.md) page is a stripped-down, plain-text version of your web page that contains only the essential content — headings, body text, links, and tables — with none of the HTML noise (JavaScript, CSS, navigation menus, image tags, footers). LLMs were largely trained on markdown-formatted data, so they parse it faster and more accurately. Creating a markdown version of your key pages gives AI crawlers a clean, high-signal file to ingest instead of fighting through a bloated HTML document.

Q: Will having a markdown page hurt my Google rankings?

Not if the content is identical to your HTML page. The critical rule is content parity: the markdown version must reflect the same information as the HTML version. If the two differ meaningfully, search engines may flag it as cloaking — a tactic historically used to show different content to crawlers than to users — and penalize your site. Keep them in sync and you’re safe.

Q: How do I tell AI crawlers that a markdown version of my page exists?

Add a single line to your HTML <head>:

<link rel="alternative" type="text/markdown" href="/your-page.md">

This directive signals to AI crawlers that a machine-readable alternative is available. Your HTML page continues to serve human visitors and traditional search bots without any changes.

Q: How much of my page does an AI actually read?

Most LLMs cap page ingestion at around the first 100 kilobytes of content. On a typical HTML page loaded with scripts, stylesheets, and third-party calls, the actual article content can sit well past that cutoff. A markdown page resolves this by putting only the content — nothing else — in a file that’s almost always well under that limit.

Q: What is agent-centric design?

Agent-centric design means building your website so that an AI agent — which perceives pages visually, like a screenshot — can understand what’s on the page and what actions are available, without needing to click, swipe, or hover. It’s the AI equivalent of accessibility design for humans with disabilities.

Q: What website elements are most dangerous for AI agents?

The biggest offenders are: tabbed content (agents only see what’s open), carousels (agents see one slide, everything else is invisible), content loaded by JavaScript after page render (agents may not trigger it), and buttons or CTAs that rely on animation or hover states to be understood. If a screenshot of your page wouldn’t make the content and actions obvious to a stranger, it won’t be obvious to an agent either.

Q: Do I need to completely redesign my website?

Not necessarily. The goal is to apply a new lens to existing design decisions — asking “would an agent understand this from a screenshot?” at each step. In many cases, the changes are incremental: making tabs visible by default, ensuring buttons are clearly labeled, avoiding background images underneath critical text. A full redesign is only warranted if the site’s structure is fundamentally agent-hostile.

Q: What is JSON-LD and why does it matter for AI?

JSON-LD (JavaScript Object Notation for Linked Data) is a standardized format for declaring structured facts about a page — your company name, phone number, product price, event date, FAQ answers — in a way machines can parse directly without inference. Rather than an AI trying to extract your phone number from somewhere in paragraph text, you declare it explicitly in a JSON block. This reduces hallucination risk and ensures AI accurately represents your entity.

Q: Which schema types should I prioritize?

Start with the types that match your page content: Organization for company pages, Product for product pages, Course for educational content, Event for events, FAQPage for FAQ sections, and Review or AggregateRating for review content. A single page can carry multiple schema types simultaneously. Use Google Search Console’s rich results report to identify errors and missing required fields.

Q: What is LLM.txt?

LLM.txt is a plain-language file you place at the root of your site (e.g., yoursite.com/llm.txt) that explains how your website is structured — not by listing every URL, but by describing where different types of content live. Think of it as orientation instructions for an AI: “Service pages are under /services. Blog posts follow /blog/[slug]. Product pages are at /products/[category]/[name].”

Q: Is LLM.txt widely supported yet?

Not universally. Anthropic has pushed for its adoption; OpenAI has not committed. In practice, most LLMs currently appear to rely primarily on on-page content rather than reading LLM.txt. However, implementation costs almost nothing, and adoption is expected to grow. It’s worth adding now.

Q: Should I still maintain my XML sitemap?

Yes. XML sitemaps remain important for traditional search engine crawlers and indirectly benefit AI discovery through Google rankings. LLM.txt is a complement, not a replacement — the two serve different audiences and purposes.

Q: What replaces backlinks in the AI era?

Citations — your brand name appearing on credible third-party platforms, with or without a link. LLMs are trained on vast corpora that weight authoritative sources heavily. If your company or product is mentioned genuinely and frequently on trusted platforms (industry publications, community forums, professional networks), AI systems are more likely to surface and recommend you.

Q: Is it worth trying to get mentions on Reddit or LinkedIn?

Authentic mentions on these platforms still carry value — both rank well on Google and feed into LLM training data. However, both platforms actively moderate AI-generated spam, and LLMs themselves are increasingly able to detect low-quality, synthetic content. The strategy that works is genuine participation: useful content, honest answers, real engagement. Volume plays and AI-written posts are quickly discounted.

Q: Do websites even matter if the future is AI agents?

In the short to medium term, yes — websites remain the primary surface AI agents crawl for information. But the longer-term trajectory points toward APIs and Model Context Protocols (MCPs) as the primary distribution layer. If your product or service can be consumed directly by an agent via API, you bypass the website layer entirely. Building both — an optimized web presence and an accessible API — is the safest path for the next few years.

Q: What is an MCP and why should I care?

A Model Context Protocol (MCP) is a standardized way for AI agents to authenticate with and call external services. Rather than an agent browsing your website to find information, it calls your MCP endpoint directly: “What services do you offer? What’s the pricing? Book this.” Companies that expose MCP servers become natively accessible to any AI platform that supports the protocol — without the user ever visiting a website.

Q: How urgent is all of this?

More urgent than most businesses realize. Traffic declines are already happening — 30–80% drops are live, not theoretical. At the same time, only 0.04% of the world’s population is actively building with AI right now. Early movers who optimize for AI discoverability have a significant window before the rest of the market catches up. The companies that act in the next 12–18 months will be the ones AI recommends by default.

Frank Vitetta, is the founder and CEO of Orchid Box, LLM Scout, and CodeScout. LLM Scout monitors how brands are cited and represented across major AI platforms. Krish Palaniappan is the CEO of Snowpal, an API platform helping businesses build software faster.

AI + Snowpal API: Reduce Time to Market

Podcast

The People Who Spent 20 Years Becoming Experts Are About to Find Out That Experience Has Been Democratized - on Apple and Spotify.

The People Who Spent 20 Years Becoming Experts Are About to Find Out That Experience Has Been Democratized

Generative AI isn’t just automating tasks — it’s distributing the very thing that made experienced leaders valuable. For decades, seniority meant accumulated intelligence. You knew things others didn’t. You’d seen cycles, patterns, failure modes. That institutional knowledge was the moat.

Kelly’s argument is that the moat is filling in. “Most leaders are where they are today because of their expertise,” she says, “but what happens when that becomes democratized?” When a junior employee with the right prompt can surface the same analysis a 20-year veteran could, the value equation changes completely. What leaders offer can no longer be just what they know. It has to be something harder to replicate — judgment, trust, the willingness to be accountable for decisions made in ambiguity.

That shift is why Kelly insists we’re not in a technology moment. We’re in a leadership moment.

AI + Snowpal API: Reduce Time to Market

Middle Managers Aren’t Obsolete — They’re Just Being Asked to Do Something They Were Never Trained For

The tech industry has a running fantasy: flatten the org, cut the middle, let AI coordinate what managers used to. Kelly thinks this is a mistake, and she’s blunt about why.

Middle managers are already the most burned-out segment of the workforce. They’re sandwiched between a C-suite selling an AI vision that isn’t fully real yet, and a workforce eager to use tools their companies haven’t figured out how to deploy. “The tools are not quite where some of the C-suite and board thinks they are,” she says. Meanwhile, managers are expected to execute a transformation that hasn’t been designed.

The role isn’t disappearing, but it is changing in a specific direction. The old job — relay information up, execute instructions down — is shrinking. The new job is orchestration: figuring out which work gets done by humans, which by AI agents, and how to hold that hybrid accountable to outcomes. It’s messier, more political, and more human than ever. The managers who survive won’t be the ones who master the tools fastest. They’ll be the ones who can navigate the parts of organizations that AI genuinely cannot touch.

That said, Kelly draws an important distinction between product companies and everyone else. In a product company, middle managers typically contribute directly — they’re in the codebase, the architecture, the design decisions. Their expertise justifies their seniority. In government agencies or traditional consulting hierarchies, where tenure drives promotion more than output, the calculus is different. If your job is coordination without contribution, AI makes it very difficult to justify that role.

Nobody Actually Knows How Many AI Agents Their Company Needs, and That’s the Problem

Krish put a question to Kelly that she called “a billion-dollar question for consulting companies”: who decides how many AI agents a company deploys, and how do you separate the ones every team shares from the ones that are specific to a single function?

The honest answer right now is: nobody has figured this out cleanly. What Kelly is seeing in practice is experimentation without governance — teams spinning up agents independently, in parallel, without coordination. The result isn’t efficiency. It’s complexity. “I have more complexity, not efficiency, because of all these AI agents I’m trying to manage,” is the phrase she keeps hearing from inside organizations.

Her prescription is a shared leadership agenda anchored at the C-suite level. The CHRO needs to be in the room, not just the CTO and CIO. HR, which has historically been left out of technology decisions, has the exact expertise this moment demands: how do you design work, structure spans of control, and build organizations around outcomes? Those questions don’t have technical answers. They have human answers. And HR is where that knowledge lives.

The principle Kelly keeps returning to is simplification. Before adding more agents, define what you need at the enterprise level and at the functional level, and be ruthless about eliminating overlap. The companies winning with AI aren’t the ones running the most experiments. They’re the ones that have decided what they’re actually trying to accomplish.

CEOs Are Saying “AI” 17 Times Per Earnings Call While Their Dev Teams Are Still Figuring Out the Tools

There’s a gap between the AI story being told and the AI reality being lived, and Kelly names it directly. Leaders know that positioning their company as AI-enabled can mean a two-to-three times valuation lift. The incentive to overclaim is enormous. And so they do.

Meanwhile, the teams actually building things are still working through which tools are ready for production, which workflows have genuinely changed, and which “AI transformation” initiatives are really just rebranded pilots that haven’t shipped. The board gets the aspirational version. The engineers get the uncertainty.

This isn’t always cynical — some of the gap is genuinely a lag between where the technology is heading and where it is right now. But Kelly doesn’t let leaders entirely off the hook. The fundamental problem is that most companies have invested heavily in AI tools without doing the hard downstream work: redesigning the job, rebuilding the workflow, doing the change management that actually makes transformation stick. She’s seen what that takes in consulting. It’s an 18-to-24 month roadmap, minimum. Most executives are measuring progress by next quarter.

The SaaS Apocalypse Is Probably Overblown — But the Market Doesn’t Seem to Have Decided Yet

Krish raised the SaaS conversation with something real: Atlassian went up 40% on earnings, then added another 5% the next day. Workday, Salesforce, Asana, Monday — companies that had been hammered for a year — are bouncing. The market keeps changing its mind.

Kelly’s read is that this whiplash is structural. Most of the broader economy is in a low-to-no-growth environment. That’s not purely an AI story — macroeconomic complexity is doing a lot of work here. But it means that AI stocks are essentially holding up the equity markets, which creates an outsized sensitivity to any signal about AI’s actual progress. Jensen Huang’s position — that SaaS companies need to evolve but aren’t going away — is closer to Kelly’s view than the doom narrative. These companies have distribution, customer relationships, and institutional trust that takes years to build. AI doesn’t make those irrelevant overnight. It does, however, require them to rethink what they’re selling and how they’re delivering it.

The Consulting Industry Built Its Junior Pipeline on Tasks That AI Now Does Better, Cheaper, and Faster

Kelly grew up in consulting. She knows the model: junior staff spend two years learning the craft through PowerPoint decks and memos, billing at a premium while absorbing industry knowledge from senior partners. That pipeline produces the partners of the future.

The problem is that AI has made the first half of that equation untenable. “You don’t need that junior consultant anymore to do that deliverable,” she says. AI can produce a polished analytical deck faster and cheaper than a first-year analyst, without the overhead. If the business case for hiring junior consultants was always partly about developing future partners, that calculus just got a lot harder.

The second challenge is more fundamental. What you hire McKinsey or Deloitte for is intelligence — the framework, the insight, the perspective accumulated across hundreds of engagements. That is precisely what generative AI is democratizing. The consulting model has to move toward problems that are genuinely hard: change management, human dynamics, the ethics of automation, the decisions that require judgment that can’t be offloaded. Firms that keep selling software implementation and document production are going to feel the pressure first.

Managed services faces an even steeper reckoning. The large-scale outsourcing model — teams in the Philippines and India handling operations at volume — maps almost directly onto what AI automates. Kelly is candid that she worries about what this means for countries where those jobs represent significant economic opportunity. The question of responsibility — who thinks through these consequences before making the switch — isn’t a business question. It’s an ethical one.

The Economy Looks Fine Until You Realize It’s Being Held Up by One Sector

The K-shaped economy isn’t a metaphor. It’s a description of what’s actually happening: returns to capital and highly-skilled knowledge work are accelerating, while pressure mounts on everyone else. The upper tier keeps spending. Luxury travel, airlines, fine dining — demand stays strong. Spirit Airlines goes bankrupt. Both things are true at the same time.

Kelly isn’t panicking, but she’s watching the lagging indicators that don’t show up immediately: credit card debt rising, spending rotating toward necessities, the compounding effect of price pressure on anyone living without a significant financial cushion. Q3 and Q4 of this year, she thinks, will be telling. The part of consumer spending that looks healthy right now may be masking a delayed adjustment.

The deeper point she makes is about interconnection. The U.S. economy is not an island. Supply chains, outsourcing relationships, oil markets, demographic shifts in Asia — all of it connects back. When companies automate away managed services jobs in India, that has consequences that eventually ripple through trade, through goods, through prices here. “The bagel you go get for breakfast has tremendous world economic consequences,” Kelly says — and most of us haven’t thought about the chain that produced it.

The New Skill Isn’t Learning to Code — It’s Learning to Unlearn

The most surprising advice Kelly offers doesn’t come from a workforce development framework. It comes from a long look at what AI actually can’t do. Empathy, wisdom, ethical judgment, creativity, the ability to hold complexity and act in ambiguity — these aren’t soft skills. They’re the hard ones. They’re the ones nobody has systematically developed, because the STEM premium made everything else feel optional.

Her read: the professions most immune to AI automation aren’t the ones that sound impressive on a LinkedIn profile. They’re healthcare, education, skilled trades. There are already labor shortages in all three. The culture hasn’t caught up — it’s still glamorizing the path of the YouTube influencer, the vibe coder, the growth hacker. But the plumber and the electrician may end up significantly better positioned in the economy that’s actually forming.

Krish offered his own version of the same idea from the builder’s perspective. The new skill, in his words, is not any particular language or algorithm. It’s “how do I solve this problem better using the current suite of people, agents, technologies, and the changing dynamics of the larger world?” The muscle memory that made experienced engineers valuable — the deeply ingrained patterns of how software gets built — is now partly a liability. The engineers who thrive will be the ones who can unlearn it.

Kelly loved that framing: “That might be your snippet for social sharing.”

The Decisions We Make About AI Today Will Shape Things for Generations

Kelly’s closing wasn’t hedged. She believes this moment is genuinely consequential — not in the hype-cycle sense of transformative technology, but in the sense that the choices leaders make right now about how to use AI, and how to treat the people displaced by it, will compound.

Her book, Reclaim the Plot, is written as fiction, drawing on real patterns she’s observed across tech and consulting without naming anyone. The central argument is that leaders keep chasing new technologies at the expense of people, and that this moment requires something different: an active rewriting of the story, not just an optimization of the current one.

The session ended the way all good conversations do — a little open, a little unresolved, with more questions raised than answered. Kelly’s dinner order was sushi, steak, and New York cheesecake. Krish’s assessment: she’s not saving that thousand dollars a month.

Listen to the full conversation on the Snowpal Podcast. Check out Dr. Kelly Monahan’s new book, Reclaim the Plot: How Leaders Rewrite the Story When AI Rewrites Work.

AI + Snowpal API: Reduce Time to Market

Sections

1. Augmentation over automation — why human-in-the-loop is a legal necessity, not timidity

2. LLM Ops in practice — how Arise, test sets, and iterative prompt tuning enforce reliability

3. Base LLMs, RAG, and differentiation — where the moat actually lives (and how it evolves)

4. The AI gateway — multi-tenancy, PII removal, prompt injection guards, and model flexibility

5. Token economics and ROI — the 3× budget overrun and how departmental accountability replaced centralised approval

6. SDLC transformation — halved time-to-merge, citizen developers, and the guardrail standardization challenge

7. The SaaS landscape — why trust and compliance posture compound into a durable moat

8. Context windows and the horizon — what becomes possible as context limits expand

Podcast

Trust the Guardrails: Building AI That Governments Can Actually Use — on Apple and Spotify.

1. Augmentation Over Automation: The Public Sector Constraint

The starting point for any AI deployment at EUNA Solutions is a deliberate philosophical choice: keep a human in the loop. This is not timidity — it is a response to the legal and regulatory realities of government procurement, grants, and budget management.

“There’s a strong bias for augmentation instead of automation... It’s about trust, explainability and transparency. We cannot roll out any agentic solution that we have not tested thoroughly.”

Stockwell’s concrete example — Euna Solutions’ AI solicitation agent — illustrates the principle sharply. The agent analyses Request for Proposal (RFP) documents and suggests categories a procurement officer may have overlooked. For a fire engine RFP, the system might prompt an official to specify hose diameter or wheel size. But it stops there deliberately.

“We cannot say to them the hose diameter needs to be X or Y, because then we kind of hold liable.”

The boundary between recommendation and prescription is not a product design preference; it is a legal firewall. Every guardrail, every observability hook, and every evaluation run exists to enforce that line in production, not just in staging.

2. LLM Ops in Practice: Building Confidence Before Go-Live

With liability stakes this high, Euna Solutions treats LLM observability as a first-class engineering discipline, not an afterthought. The team uses Arise — an LLM ops and observability platform — alongside alternatives such as LangSmith and LangFuse, to evaluate agents outside production before release.

“We have the system prompt, we have the agent, and then we run a standardised test set through Arise and we have an expected result that we want. And we have the actual output that was outputted from the LLM. And then we were able to see the difference between the two, adjust the system prompt and rerun those evaluations again to make sure we’re getting the level of accuracy that we want.”

The same observability loop runs in production. Drift in model output — inevitable as underlying models are updated by providers — is caught early and corrected by updating system or guardrail prompts before customers are affected.

The Guardrail Feedback Loop

Guardrails at Euna Solutions are product-specific rather than generic. For each feature, product managers and engineers define what the model must not output. The guardrail layer intercepts every agent response and re-prompts the model if the response violates a rule — iterating until the output is compliant before it is surfaced to the user.

“The guardrail reviews it. If it’s not [acceptable], it goes back to the agent and it keeps iterating until the response gets back. And then it’s populated in the front end for the customer to see.”

This architecture means that test coverage at the system-prompt level becomes a form of regression testing. QA engineers own the evaluation suites; software engineers own the prompts. The distinction matters because evaluation quality is ultimately a domain knowledge problem, not just a technical one.

3. Base LLMs, RAG, and the Question of Differentiation

A natural question arises: if the solicitation agent is powered by a base LLM with no proprietary fine-tuning, what stops a competitor from replicating it? Stockwell’s answer is pragmatic and instructive for anyone building in the LLM application layer.

“These large language models are trained on billions of parameters of data. So they have all those public RFPs that have been published in the past in them... The system prompt is probably the most important in this. That is a very, very long prompt, a lot of tokens where we give it examples of how we want it to output. We give it the wording that we want it to use. We give it different scenarios.”

The moat, in the near term, is prompt engineering depth, evaluation infrastructure, and the guardrail layer — not proprietary model weights. Over time, Stockwell anticipates a migration toward fine-tuned models or Retrieval-Augmented Generation (RAG) pipelines seeded with the company’s accumulated private data.

RAG as a Shared Capability

RAG is not just a customer-facing feature at Euna Solutions — it is an internal developer productivity tool. The team has built reusable RAG patterns that engineering teams can adopt by pointing their data at a managed vector store (currently AWS OpenSearch) and calling through the AI gateway.

“If you want a RAG agent, it’s a pretty easy thing to deploy, here’s the pattern. All you have to do is shift your data into this vector store, call it through the AI gateway, choose a large language model. Here’s Arise that you can use for testing. And that’s kind of enabled them.”

One illustrative internal application is developer tooling built on top of MCP (Model Context Protocol) servers, which give AI agents contextual knowledge about SharePoint, Salesforce, or role-based access control systems — reducing the friction of context-gathering in an engineering session.

4. The AI Gateway: Multi-Tenancy at the LLM Layer

Euna Solutions serves multiple government entities, each with their own data isolation requirements. The core architectural solution is a centralised AI gateway through which every LLM API call flows, regardless of which product line triggers it.

“Every single API call to a large language model goes to that AI gateway. And then we split the gateway by the different products. So we have like a procurement entry point, the grants entry point, a budget entry point broken up by the products. And we were able to see which customers are calling the model, what their token spend, what their limit is.”

Beyond multi-tenancy and billing visibility, the gateway serves as a unified enforcement point for cross-cutting concerns. Toxic language filtering, PII removal, SQL injection prevention, and prompt injection guardrails all live at this layer — applied consistently across every product without requiring each engineering team to re-implement them.

Model Flexibility and Cost Optimization

The gateway also enables provider-agnostic model selection. Engineering teams can evaluate expensive frontier models against cheaper, lightweight alternatives using the same evaluation harness and choose based on accuracy data rather than intuition.

“We can take an expensive large language model and we can take something like Gemini Flash and test it and see what the output is. And if they both give me the same accuracy, I’m going to take the cheaper one.”

In customer-facing contexts, this flexibility could eventually become a product feature — allowing government agencies to choose a model tier based on their accuracy requirements and budget, with pricing attached to that choice.

5. Token Economics and the ROI Question

Enabling Claude across the organization at Euna Solutions produced an immediate and instructive result: token spend ran to roughly three times the projected budget. The experience offers a candid case study in enterprise AI governance.

“We enabled Claude and we thought our budget would be X and it’s like three times X because of the usage... We kind of narrow it in and we say, hey, you spent $5,000 on X this month. What did you use it for? Log it in the AI innovation hub and what’s the return on investment?”

Stockwell’s response was to build an AI Innovation Hub — an internal tool where employees log their AI projects, enabling leadership to tie token spend to concrete outcomes. The shift in governance model is noteworthy: rather than centralised approval for every use of AI, departmental leaders are accountable for demonstrating ROI within their own teams.

“I should not be approving your token usage if you’re in finance or if you’re in HR... it should be the leaders in those areas understanding what their employees are using AI for and making sure that they’re using it in a way that we are getting a positive ROI from it.”

One employee, for example, completed a documentation project in four months that would have taken twelve — a result that justified elevated token consumption. The AI enablement team’s role is not cost policing but process re-engineering: helping teams understand whether an AI automation is truly the right solution, or whether the underlying process should be redesigned first.

“Instead of just, ‘should we automate this?’, it’s like, ‘can we take a step back and let’s look at the entire process to see if this is really an AI automation, is it something that Claude should be doing, is it a software engineering process?’”

6. SDLC Transformation: Speed, Quality, and the Guardrail Gap

Euna Solutions has a dedicated team focused solely on SDLC transformation through AI. The headline metric is time-to-merge-request, which has dropped by approximately half as developer adoption of AI tooling has increased.

“It’s still two weeks [sprints], but we’re able to get through a lot more in those two weeks.”

Early adopters within engineering teams have begun building their own agent-based review pipelines — ad hoc solutions to code quality and risk concerns that arise naturally as AI-generated code enters production codebases. The challenge for the AI platform team is standardizing these patterns so their benefits are available to all engineers, not just those who built them.

“As our developers start using it, they start building up their own agents within the different solutions to mitigate the risks that they’re seeing — they’ll have a review agent, they’ll have this agent. And now what we kind of have to do is figure out how do we standardise that so that all developers have access to these different things.”

Claude Code has been central to this internal transformation. Non-technical staff in HR, marketing, legal, and finance are now building their own internal applications — a dynamic that is surfacing new questions about production readiness checklists, SDLC governance for citizen-developed apps, and how to enforce coding standards outside traditional engineering pipelines.

7. The SaaS Landscape: Threats, Opportunities, and the Adoption Curve

The conversation broadened to the macro question of what AI means for SaaS companies as a category. Stockwell’s view is nuanced: the threat is real, but the response is within reach of any company willing to move quickly and invest in AI capability.

“You can go get a Replit account or Lovable and vibe code something very, very quickly. Governments move in this space pretty slowly, and there’s definitely a trust component to this. So we’ve kind of built over years all the guardrails, not just from an AI perspective, but from a data and infrastructure perspective.”

The compound moat — compliance posture, data trust, customer relationships, and now AI platform depth — is harder to replicate than any individual feature. The risk is not that AI replaces Euna Solutions outright; it is that a nimbler competitor replicates enough functionality fast enough to win new contracts.

“If you kind of have a vision — instead of pushing out five product features a year, you can maybe push out ten because you’re using AI and you’re using more and more tokens to produce things.”

Stockwell’s broader framing of the adoption curve is a useful corrective to the hype cycle. The majority of potential users have not yet meaningfully engaged with AI tooling. Teams and organizations that move quickly across that curve — in Stockwell’s words, “as quickly as possible” — are building a lead that will compound as the curve steepens.

8. Looking Ahead: Context Windows, Vibe Coding, and the Horizon

Two technical constraints define the current ceiling of AI-assisted software development in Stockwell’s view: context window size and the maturity of evaluation infrastructure. Both are moving.

“What’s stopping a company right now from taking their current software application and giving it to an AI agent and saying, ‘take this and redo X, Y, and Z with these features and deploy it’ is context. The context window is too small. It cannot take all the tokens into account of your entire codebase. But if I have to look about this — maybe a year, maybe two years from now, maybe even sooner — that’s not going to be an issue.”

The implication is that organizations building strong AI posture now are positioning themselves for a qualitatively different capability in the near term. The teams and companies that have invested in observability, guardrails, prompt engineering depth, and developer education will be able to absorb larger context windows and more autonomous agents without starting from scratch on governance.

His advice to teams navigating the current pace of change is to resist the temptation to over-engineer.

“People try and sometimes overcomplicate things when you can do a very small pilot project. It’s very easy to build an agentic pattern and it’s very easy to productionize it once you have the capabilities — your LLM ops, your guardrails. And there’s a lot of value that we can already get to our customer just by embedding a basic LLM powered by an agentic solution.”

Technologies

At Euna Solutions, every LLM API call — whether targeting Claude, Gemini Flash, or any other provider — is routed through a centralized AI gateway that enforces rate limiting, token metering, PII redaction, toxic language filtering, and prompt injection guardrails before a single token reaches a customer-facing surface. Atop that gateway sits a stack of reusable agentic patterns: RAG pipelines backed by AWS OpenSearch vector stores, Lambda functions for serverless orchestration, and MCP (Model Context Protocol) servers that give agents contextual awareness of enterprise systems including SharePoint, Salesforce, and role-based access control environments. Each pattern is observable end-to-end through Arise, an LLM ops platform analogous to LangSmith and LangFuse, which runs standardized evaluation sets against expected outputs both in pre-production and live environments — enabling the team to detect prompt drift, adjust system prompts or guardrail prompts, and rerun evals before any degradation surfaces to users. The guardrail layer itself operates as a feedback loop: agent responses are intercepted, evaluated against product-specific constraint rules, and re-submitted to the model iteratively until compliant output is produced, at which point it is passed to the front end.

On the developer productivity side, Euna Solutions has embedded Claude and Claude Code across engineering, HR, marketing, legal, and finance, producing a measurable 50% reduction in time-to-merge-request without shortening two-week sprints — the same cycles now yield significantly higher throughput. Engineers across product lines, spanning AWS, Azure, and GCP infrastructure inherited through acquisition, are building bespoke dev-side MCP servers and autonomous review agents to validate AI-generated code against production readiness checklists, effectively creating team-local SDLC guardrails that the AI platform team is now working to standardize organization-wide. Model selection is treated as an empirical rather than intuitive decision: the AI gateway enables side-by-side evaluation of frontier models against lightweight alternatives like Gemini Flash, with accuracy benchmarked against the same Arise test sets used in production monitoring, so cost optimization is grounded in observed performance deltas rather than vendor claims. Fine-tuning and expanded RAG coverage — augmenting base LLMs already trained on billions of public parameters including historical RFP corpora — remain the planned evolution path as private data assets mature and context window constraints, currently the binding limit on whole-codebase agentic refactoring, continue to expand.

Conclusion

The technical story that emerges from Andrew Stockwell’s experience at Euna Solutions is less about any single model or framework and more about infrastructure discipline. The companies and teams succeeding with AI in regulated, high-stakes environments are not doing so because they have access to better models — they are doing so because they have invested in the layers that make models trustworthy: rigorous evaluation pipelines, purpose-built guardrails, centralised observability, and a culture of measured experimentation over speculative automation.

As Stockwell put it in his closing remarks:

“Don’t look at it from a negative point of view. Look at it from a positive point of view and just have the right vision and strategy to execute on it. Anyone can do anything now. I can take anyone who’s never coded and they can vibe code an app or an idea. So there’s so many opportunities.”

The technical foundations Euna Solutions has built — an AI gateway, reusable agentic patterns, LLM observability, and a governed AI innovation hub — are a blueprint for any software organization trying to ship AI responsibly at scale. The tools are largely available. The discipline is the differentiator.

About the Guest

Andrew Stockwell is VP of AI at Euna Solutions, a cloud-based software provider for public sector organizations in the United States and Canada. His background spans actuarial economics, data science, and a Master’s degree in Computer Science. He has led AI platform, enablement, and LLM ops initiatives across multiple organizations, with a focus on responsible deployment of generative AI in regulated environments.

About the Snowpal Podcast

The Snowpal Podcast explores the intersection of technology, software architecture, and entrepreneurship. Episodes feature practitioners sharing hands-on experience building and deploying software at scale. Hosted by Krish Palaniappan, founder of Snowpal.

What happens when a former Wall Street fintech co-founder decides to stop building products for institutions and start building them for people — specifically, for women who’ve been told, in one way or another, that finance just isn’t for them?

You get: Her Financial IQ.

I recently had the pleasure of sitting down with Jessica Perrone, founder of HerFinIQ.com, for a wide-ranging conversation on financial literacy, investing anxiety, the role of culture in money habits, and where AI fits into all of it. It was one of those conversations that was genuinely hard to cut short — and I promised Jessica we’d do a follow-up to go even deeper.

Here’s a recap of what we covered.

AI + Snowpal API: Reduce Time to Market

Podcast

Making Finance Less Scary — on Apple and Spotify.

Why Women? Why Now?

The first thing I asked Jessica was the obvious question: why focus specifically on women when financial illiteracy affects everyone?

Her answer was thoughtful. She runs a co-ed platform called FinIQ.edu too — because the topics of finance are the same for everyone. But the way those topics land is often very different.

“Women have only had financial rights since the 1970s,” Jessica pointed out. “We don’t think about how recently women were given the right to own a credit card without the cosigning of their husband or their dad.”

That history, she argues, doesn’t just disappear. It gets passed down — in the form of anxiety, avoidance, and silence. When women are in mixed-gender rooms discussing money, they tend to go quiet. They defer. But in a room full of women, something shifts. It becomes more like a coffee talk than a lecture, and real questions get asked.

That’s the environment Jessica has spent six years creating.

Two Real-Life Examples That Tell the Story

I shared two Instagram videos I’d come across that stuck with me. In one, a young woman in her mid-20s had financed a Tesla for $94,000 — $1,000 a month for 90 months, plus a $4,000 down payment — on a car likely worth around $60,000. In another, a woman going through a divorce realized she had no idea what her family’s finances looked like because her husband had handled everything.

Jessica didn’t flinch. “These are two very real situations that I see frequently,” she said.

The root cause? No one’s having the money conversation at home. Nobody’s teaching the ratios — what percentage of your income should go to housing, to a car payment. “Loan officers and car salespeople are going to push you to think you can afford more than you really can,” she said. “Educating yourself on your budget and your credit score is so important.”

It’s not just a women’s issue, either. As Jessica put it — financial blind spots show up across genders. What matters is that someone starts talking about it.

Investing 101 (Before You Even Think About Stocks)

We spent a good chunk of our time on investing, and Jessica made a point that I think gets overlooked too often: you can’t talk about stocks until you talk about how to invest.

“Before you understand what a P/E ratio is, you have to understand what a stock is,” she said.

Her own story reinforced this. When she first had money to invest, she dove into self-directed trading — convinced she could learn by doing. It didn’t go well. She didn’t understand how stocks move with the economy, the difference between safer large-cap names and riskier plays like Bitcoin, or what kinds of accounts to use for what kinds of goals.

“If you want to buy a car next year, you don’t want your money in the markets,” she explained. “You want it in more liquid accounts — maybe a high-yield savings account.”

Her courses now start there: the buckets, the time horizon, the type of account, the risk level. Then, once those foundations are in place, you can start thinking about individual investments.

Diversification Is More Than Just “Don’t Put All Your Eggs in One Basket”

I pushed back a bit on the idea of diversification — citing Peter Lynch’s point that you can over-diversify to the point where your returns get diluted. Jessica’s response clarified something I found genuinely useful.

She’s not just talking about diversifying assets. She’s talking about diversifying risk levels.

“I have my self-directed account, which is more risky. I have my robo-advisor account, which is managed and in ETFs — less risky. And then outside the markets, I have real estate and cash.”

The idea is that you benchmark each account against something like the S&P 500. If your self-directed portfolio isn’t beating — or at least keeping pace with — the index, that’s information. If your robo-advisor isn’t protecting you on the downside, that’s information too. Multiple accounts give you data to work with, not just hope.

“That benchmarking allows me to not second-guess myself,” she said. “And to be more confident as a self-directed investor.”

Risk Tolerance Isn’t Fixed — It Grows With Education

I used my wife and myself as an example here. She’s conservative — ETFs, metals, savings accounts. I’m on the other end of the spectrum (I may or may not have had money on Meta going into earnings that afternoon). How do two people learn from the same curriculum and apply it so differently?

Jessica’s answer surprised me: “Your wife, after taking my courses, will have a risk tolerance that’s closer to yours.”

The point isn’t that everyone should become an aggressive investor. It’s that most people’s risk tolerance is artificially low — not because of their actual personality, but because of a lack of understanding. Once you understand how different assets work, what your time horizon is, and how to structure accounts accordingly, you can make choices that actually fit you. Her courses include real risk tolerance questionnaires that financial advisors use, and map those results to actual asset strategies.

“There’s no right or wrong,” she said. “It’s just about doing it the safest way that will give you the most growth for your risk tolerance.”

Culture, Community, and the Village

I asked Jessica about something I’ve observed firsthand: how much of financial behavior is cultural, not just educational? Growing up in India, I watched women in my family invest in gold not because they’d studied asset allocation, but because that’s what their mothers did.

Jessica’s answer was one of my favorites from the whole conversation.

“Women go into their communities and they teach their daughters, their husbands, their sons, their sisters, their brothers, their mothers, their fathers, their cousins, their neighbors. And then they lift up the whole community.”

She shared the example of working with refugees from Nepal who had never interacted with a formal financial system — not a bank account, not a budget, nothing. Education, she said, has to meet people where they are. That’s why her curriculum spans everything from basic banking and budgeting all the way through advanced investment strategies.

The App (and the Vision)

Here’s something I’ll call out specifically because it came up almost serendipitously in our conversation: Jessica is building an app.

When I floated the idea of a tool that could learn your risk profile from your behavior and allocate money algorithmically — essentially a pocket financial advisor — Jessica basically said: that’s what I’m building.

“I want to start with individuals’ finances, help them figure out where their buckets go, and then once they have their buckets and their budget, become an allocator,” she said. “I want to democratize allocation.”

The dream is an ecosystem where users can manage their personal finances, understand their risk tolerance, and then allocate to financial products — 529s, 401ks, investment accounts — with minimal friction, guided by their actual profile.

We heard it here first.

Final Thoughts

What struck me most about Jessica is that she talks about finance the way a good coach talks about their sport — with genuine excitement, no condescension, and a real belief that everyone can learn. Not everyone needs to trade individual stocks. But everyone deserves to understand their money, and everyone deserves to feel confident walking into a conversation with a financial advisor, a loan officer, or even a car dealership.

If you’re someone who gets anxious when the topic of money comes up — or if you know someone who is — check out HerFinIQ.com. There’s also a co-ed version of the curriculum at FinIQ.edu for anyone who wants to learn alongside a partner.

And yes, Jessica — I’ll tell my wife about the courses.

Summary

At Snowpal, we’ve been building a FinTech API because we kept seeing the same gap — people making financial decisions without the right tools, information, or infrastructure underneath them. Whether it’s a first-time investor who doesn’t know the difference between a brokerage account and a Roth IRA, or a platform trying to offer personalized financial guidance at scale, the plumbing just isn’t there. Our API is designed to change that: giving developers and product teams the building blocks to embed intelligent, personalized financial functionality directly into their apps — without starting from scratch.

That’s exactly why a conversation like the one we had with Jessica Perrone of HerFinIQ resonates so deeply with us. Jessica’s vision — an ecosystem that meets users where they are, understands their risk tolerance, and allocates their money intelligently across the right accounts — is precisely the kind of product our API is built to power. Financial education creates the awareness; the right technology closes the loop. Together, they turn knowledge into action. That’s the future we’re building toward at Snowpal, and we think it’s closer than most people realize.

Jessica Perrone is the founder of Her Financial IQ, a financial education platform for women. She offers online courses, corporate workshops, and group coaching programs. Find her at HerFinIQ.com or on LinkedIn.

AI + Snowpal API: Reduce Time to Market

Podcast

Who Needs Developers? (Everyone, Actually) - on Apple and Spotify.

From Moscow to the World: A Founder’s Journey

Asia Solnyshkina did not plan to become a global founder. In March 2022, when war broke out between Russia and Ukraine, she left Moscow with little more than her laptop and her two children. There was no plan, no destination, no certainty about what would come next.

“I left Russia with just my laptop and two kids,” she recalls. “Basically with no plan of what I will be doing, how I will be managing my company.”

What followed was a journey across continents. First Georgia, then three years in Mexico City — “a brilliant, beautiful place” — and now an attempt to settle in the United States. Her company, ProSense Digital, builds custom software for businesses worldwide: ERP systems, CRMs, websites, and complex automation tools. Clients range from the United States to Latin America to Australia.

The eight-year-old company was remote from the start, which softened some of the disruption. But rebuilding a business across countries, time zones, and cultures forged something more durable than any office could: resilience paired with agility.

“I do feel that right now I can adapt to the new world a lot,” she says, “because I’ve been traveling, I’ve been meeting different people, I’ve been working with different businesses, rebuilding the whole structure, the whole company, losing partners and all of this. I feel comfortable in this new AI era, which is pretty fast.”

What Good Design Actually Means

Working across Russia, Latin America, Australia, and the US revealed striking differences in how clients approach software. In Russia, Asia found, clients often arrived focused on aesthetics — the pretty button, the beautiful interface — sometimes at the expense of the underlying system.

“What I felt about building business in Russia was, it was all about, let’s do the pretty UI. And that’s it. We’re not thinking about the UX,” she explains. Her work became as much about education as engineering: helping clients see that beneath every button there must be a system that serves a real business goal.

This is where the conversation got pointed. What does “good design” actually mean to engineers who want specifics, not adjectives?

For Asia, the answer is unromantic: good design is design that converts. Amazon, with its dense interface and relentless commercial focus, is good design. Award-winning agency sites with floating parallax and ornate animations often are not. “I’m not thinking about how beautiful it is, I’m thinking about the goals. I’m thinking about what people are trying to achieve.”

That definition is debatable — and Krish pushed back. Plenty of well-designed products fail to find product-market fit, derailed by timing, capital, or distribution rather than craft. But the underlying point holds: design exists to serve business outcomes, not to win Dribbble shots.

The AI Inflection: Cheaper Software, More Software

A reasonable prediction, repeated for years, holds that AI will end software development as a profession. Asia’s lived experience contradicts it.

“I’ve been told for years in a row that software development will be dead like in a year, in a month or so. Right now what I’m experiencing with my exact business — it’s actually not just thriving, but my client base grew.”

This echoes the Jevons paradox: when something becomes cheaper to produce, demand often expands rather than contracts. Software is following the pattern. Businesses that once viewed custom development as expensive and slow now see automation as accessible — and they are bringing more problems to the table than ever.

Asia’s design and prototyping process has changed dramatically. Where her team once spent weeks in Figma, iterating through three or four rounds before showing clients anything tangible, they now prototype directly in tools like Lovable. By the time the polished design would have arrived under the old process, the market itself might have shifted.

“The main essence of what we’re doing is prompt engineering,” she says. “Creating a good task for AI so it could understand the problem we’re trying to solve. Not drawing beautiful buttons, but solving the real business problem.”

The Managed Services Question

If anyone with a credit card and a Lovable subscription can build software, what is a managed services provider actually selling?

Krish pressed on this directly. The traditional moat — knowing a particular language, framework, or architecture — has weakened as tools generate working code from natural language. So what does Asia’s company offer that a curious non-engineer cannot do alone?

Her answer pivoted away from the tool entirely. “I’m not using just the tool, because the tool is just the tool. I’m using my experience working 15 years in software development.” More importantly, she argues, ProSense Digital is not a body shop selling hours — it is a product company selling outcomes.

“We’re not trying to sell just the lines of code. We’re trying to sell the complete products that helps people with whatever they need.”

What AI changes for her company is leverage, not category. Experiments that once cost real money — A/B tests, prototype iterations, market probes — now cost almost nothing. That makes it easier, not harder, to do the thing she has always sold: understanding what users actually need versus what they say they need.

The honest concession: she may be wrong. “Probably in a year or two, I will have to go to some other business. But right now I do feel like this. We’re building products.”

What Founders Get Wrong

Asked what founders most often get wrong when scaling, Asia gave an answer rooted in the cost of conviction. Founders fall in love with their original idea and refuse to let market signal change their minds. “Sometimes founders stick to their ideas even though they are in the process of developing the product itself, they do understand that probably this idea is not right. But they’re investing a lot of time, a lot of money and a lot of everything.”

The discipline she advocates is experimentation as default. Talk to users, watch behavior, run tests, and accept that what people say they need is rarely what they actually need.

The conversation circled into a productive disagreement here. Krish raised the Henry Ford line — that customers asked for faster horses, not cars — and the iPhone launch, which Asia herself remembers as underwhelming at the time. Sometimes great products are not validated by initial reception. Sometimes the surveys say no and the founder presses on anyway.

The synthesis: even the giants get this wrong. Meta’s Metaverse spend, Google’s graveyard of canceled products, and the cool reception to Meta’s smart glasses all suggest that even well-resourced teams build products for ego, for investors, for narrative — not always for users. Asia’s framing: “Sometimes people are building products not to be successful.” It is a sharp observation about R&D, ego, and the pressure to appear ahead.

The Future of Software Development

Krish offered a candid read on his own field after more than two decades in it. Software has never been static, but the pace of change in the last two years is different in kind, not just degree. Several things have shifted:

The fundamental shift is that he no longer needs a developer to build software. After 20 years of always needing one, that assumption is gone.

Hiring is harder to think about, not easier. Yes, anyone can use these tools. But if a hire cannot reason from first principles about persistence layers, about why Postgres versus DynamoDB, about architecture trade-offs — then what value do they add beyond what the model already provides?

Architecture itself is changing. Engineers with muscle memory from the previous era have to actively unlearn old patterns. Newcomers have an advantage in flexibility but lack the scar tissue that distinguishes good decisions from bad ones.

The economics are commoditizing. Charging top dollar for code is over. Smaller teams shipping more software is the emerging shape. Founders report going from 54 people to 8. Yet layoffs are everywhere, and the gap between “AI made us more productive” and “we still have headcount” is closing painfully.

Production reality is more complicated than the demos suggest. AWS suffered outages that the company attributed to AI-generated code; senior architects must now approve generated changes there. Apple is rejecting vibe-coded apps from the App Store. Vibe coding is excellent for experiments and prototypes — Asia uses it actively — but production-grade systems still demand engineering judgment.

“I’m not comfortable pushing code to production that I’ve at least not seen one time,” Krish said. “I cannot have a tool generate code and then push it to production.”

Hiring in the New World

Asia’s hiring philosophy has quietly evolved into something unconventional. She does not run formal interviews. Instead, every manager keeps a stockpile of small, low-stakes tasks — the kind where a candidate failing would not damage anything important. When a CV catches her eye for curiosity and intelligence, the candidate gets one of those tasks.

“I’m observing how they are interacting in the real world setting.”

College degrees are not required. The trait she screens for, above all else, is curiosity — the willingness to engage with a world that is changing faster than any curriculum can keep up with. She is actively hiring vibe coders, not because they replace engineers, but because they extend her ability to run cheap experiments at scale.

On Jobs, Identity, and What Comes Next

Krish was direct when Asia asked whether he feared AI would take his job: “I’m not afraid because I know it is going to. I have no doubts about that. The job that I have done all these years — writing code, like every line of code — that job is gone. It’s not coming back.”

The dilemma is more subtle than replacement, though. Sometimes he sits down to write a line of code and hesitates because the tool can do it. Then the tool’s output is not quite right, so he rewrites it. At which point, why didn’t he just write it himself? The judgment about what to delegate and what to keep is a new skill, and it requires the engineering background he’s not yet willing to abandon.

“You want to use these tools to make yourself more productive, but I don’t want to use those tools to lose my agency. We are all born with a certain intellect, good, bad, or ugly. If you don’t end up using that, what is the point in living life?”

Asia’s view on AI’s broader employment impact is more optimistic. Yes, jobs will disappear. But new ones — for people who can think, adapt, and stay curious — will emerge. The transition rewards people who treat this as a moment to experiment, not a threat to defend against.

The Future of Managed Services

The managed services model for custom software development is undergoing a fundamental structural shift driven by AI-assisted code generation and rapid prototyping tools like Lovable. Historically, the value proposition of firms like ProSense Digital rested on deep technical expertise in specific stacks — React.js, Python, PHP — and the human capital required to translate business requirements into functional ERP or CRM systems over multi-month development cycles. Today, that cycle has compressed dramatically. Rather than spending two to three weeks on Figma prototyping followed by iterative design reviews, teams can now generate working UI prototypes through prompt engineering in a fraction of the time. The core competency has shifted upstream — away from implementation fluency and toward problem framing, requirements elicitation, and knowing what questions to ask the machine. Companies that continue to sell lines of code as a deliverable will face severe margin compression; those repositioning around product outcomes and experiment-driven iteration are finding, counterintuitively, that demand is actually growing as the Jevons paradox plays out: lower build costs are expanding the total addressable market for software.

The architectural risk introduced by vibe coding and LLM-generated codebases is becoming increasingly visible at scale. AWS’s recent production outages, attributed in part to AI-generated code reaching production without sufficient senior review, illustrate a critical gap: the speed at which code can be synthesized now far outpaces the institutional knowledge required to validate it. Key engineering decisions — selecting appropriate persistence layers (e.g., PostgreSQL vs. DynamoDB), designing for idempotency, managing stateful distributed workflows — require understanding that is not easily delegated to a generative model. Apple’s App Store rejections of vibe-coded submissions further underscore that AI-generated code often fails production-readiness criteria around security, performance, and platform compliance. The practical implication for engineering organizations is a bifurcated workflow: use AI-assisted generation aggressively in prototyping and experimentation phases, but ensure a senior architect with domain fluency reviews and approves anything moving toward production. The engineering background requirement hasn’t disappeared — it has simply migrated from writing code to governing the code that machines write.

A Final Thought on People

After a wide-ranging conversation, Asia closed with the observation that surprised her most across years of travel and work in Russia, Latin America, China, Singapore, Australia, and the US:

“All of us are people. We all are little children inside. We all have the same fears, the same joy, the same everything.”

Business cultures differ. Design preferences differ. Management styles differ. But under all of it, the people are remarkably the same — and the work, in the end, is for them.

Asia Solnyshkina is the founder and CEO of ProSense Digital, a product company building custom software for clients worldwide. Connect with her at prosense.digital or on LinkedIn.

AI + Snowpal API: Reduce Time to Market

Every company feels the pressure to go AI. Trade publications demand it. Investors expect it. And yet most AI pilots quietly fail — expensive experiments that produce dashboards nobody checks and chatbots nobody trusts. Sid Bharath, founder of Refound AI, has spent the past year helping companies move past that failure pattern. He builds AI agents for a living, runs his own business almost entirely on agents, and has a specific, repeatable framework for how he does it. In a wide-ranging conversation on the Snowpal podcast, he laid out the full playbook.

Podcast

How to Make Your Company AI-Native (Without the Hype) - on Apple and Spotify.

Let me guess. Someone in your leadership team has said the words “we need to be doing more with AI” in the last thirty days. Maybe it was a board meeting. Maybe it was a Slack message with a link to a TechCrunch article. Maybe it was you.

And so the team spins up a pilot. Buys a tool. Adds a chatbot to the website. Runs a few experiments. And three months later, the results are... fine. Not transformative. Not the productivity revolution the headlines promised. Just fine.

Sid Bharath has seen this movie dozens of times. As the founder of Refound AI — an AI consultancy that helps companies become genuinely AI-native — he spends his days cleaning up after exactly this pattern. And his diagnosis is always the same: you skipped the audit.

The Uncomfortable Truth About AI Adoption

Here is the thing nobody says out loud in AI vendor pitches: most AI projects fail not because the technology doesn’t work, but because companies deploy it without understanding their own operations first.

“The reason so many AI projects fail is you just try to do something and it doesn’t really make sense for your business,” Sid told Krish Palaniappan on the Snowpal podcast. “You can’t just pick a tool and hope it solves a problem you haven’t clearly identified.”

The FOMO is real. The pressure is real. But blindly adopting AI without understanding where your actual bottlenecks are is like hiring a team of consultants and sending them to the wrong office. The capability is there. The direction is missing.

Before you build anything, deploy anything, or buy anything — you need to know where your time is actually going.

What a Real AI Audit Looks Like

An AI audit is not a software scan. It is not a spreadsheet of your tech stack. It is a series of honest conversations with the people actually doing the work.

Sid’s team books one-hour sessions with every role in the organisation — product managers, engineers, designers, QA testers, salespeople, operations staff. The question is always some version of the same thing: walk me through your week. What takes the most time? What do you hate doing but have to do anyway?

That last question is the most revealing one. Because in every company, there is a category of work that everyone resents — the admin, the documentation, the status updates, the data entry — that nobody was actually hired to do but that somehow consumes enormous amounts of the day. That is where AI belongs.

“For some people, there’s a very clear thing they do every day where they’re like, ‘I hate doing this, but I have to do it and it takes up so much time — can you fix it for me?’” Sid said. “Those are the easiest ones.”

The audit maps the entire workflow: from how customer signals get collected and turned into product specs, through design and engineering and QA, all the way to how the product gets communicated to the market. The bottleneck is different for every company. For one it might be that product managers are drowning in Zendesk tickets and NPS surveys before they can form a single clear feature idea. For another it is that engineers ship fast but the sales team bleeds hours every day on proposal documents.

You do not know which one is you until you look.

A Concrete Example: The Sales Team That Was Losing 2 Hours a Day

Take a typical sales workflow. You have leads coming in, discovery calls being scheduled, proposals being drafted, contracts being sent, and CRMs being updated. The part that creates revenue is the conversation with the prospect. The part that eats up the day is everything around it.

Sid spoke to a sales team recently where every salesperson was spending at least two hours a day on admin — updating Salesforce, creating proposals, drafting follow-up emails, generating reports. Two hours. Out of an eight-hour day, 25 percent of each person’s capacity was going to work that a well-configured AI agent could handle in seconds.

Here is what happens when you fix that. The moment a sales call ends, an agent detects the completed meeting, reads the transcript, checks where the lead sits in the pipeline, generates a tailored proposal using the company’s existing templates, updates the CRM, and pings the salesperson on Slack with everything ready to review. Total time required from the human: thirty seconds to glance at the proposal and hit send.

The salesperson did not lose their job. They got two hours back every day to do the work they were actually hired to do — have more conversations and close more deals.

That is what a well-placed AI agent looks like. Not a chatbot on a website. An autonomous system that understands your workflow and handles the parts of it that don’t need a human.

Why Custom Agents Beat Off-the-Shelf Tools

At this point you might be thinking: can’t I just buy a tool that does this? There are plenty of AI-powered CRM integrations, proposal generators, and meeting summary tools on the market.

You can. And you will get 80 percent of the way there.

The problem is the other 20 percent. Every company has its own quirks — its own proposal format, its own CRM logic, its own approval process, its own exceptions. Off-the-shelf tools handle the generic case. They leave the specific, messy, exception-heavy details back on the human’s plate. And those details are usually the ones that mattered.

A custom agent built on your actual context — your SOPs, your templates, your business logic — can handle the full process. Not 80 percent of it. All of it.

This is what Sid calls the AI OS: an AI operating system. A single agent running on a server, connected to your existing tools, and loaded with a structured understanding of how your business actually works. The core architecture is reusable across clients. What changes is the context — the business-specific knowledge that makes the agent behave like someone who has worked there for ten years rather than something that just read your website.

The Meta-Point: Sid’s Own Company Runs on Agents

Here is where it gets interesting. Refound AI does not just build agents for clients. Sid runs his entire consultancy on the same system he sells.

When a prospect books a discovery call, an agent researches them and delivers a briefing before the meeting. When the call ends, the agent reads the transcript, drafts the proposal, and prepares the follow-up email. Every morning, Sid’s team wakes up to a digest in Discord: here is the state of the pipeline, here are the outstanding tasks for each client, here is what needs to happen today. When Sid finishes an audit interview, the agent turns the notes into a presentation deck ready for the client.

The result is a small team capable of running dozens of client engagements simultaneously. Sid cancelled most of his SaaS subscriptions. He lives primarily in his terminal, using Claude Code as his main development interface. The agents have access to Gmail, Google Drive, Discord, and a custom internal database. He does not log into most tools anymore — the agents do it for him.

“The only human work left,” he said, “is getting on a podcast, a discovery call, or doing an in-person audit interview. Everything else is agents.”

The Governance Question Nobody Wants to Skip

Running on agents sounds great until something goes wrong. And things do go wrong. Amazon made headlines recently when a series of outages were attributed to AI-generated code that bypassed engineering review. If your agents are writing to production databases, sending emails on your behalf, and updating customer records — you need to think carefully about what happens when they err.

Sid is direct about this: the answer is the human checkpoint. Every significant action an agent proposes is reviewed before it executes. The human can always abort. There is a meta-agent that monitors the operational agents and surfaces anomalies in the logs. When something goes wrong, the team diagnoses it and patches the agent’s instructions so the mistake does not happen again.

The key distinction he draws is between what he calls vibe coding — where a non-technical person tells an AI to build something and ships whatever comes out — and agentic engineering, where the agent produces the bulk of the output but a human with real technical judgment is reviewing every meaningful decision before it goes live. The first approach is how you get outages. The second is how companies like Anthropic build production systems that are 99 percent AI-generated and still reliable.

Agents are powerful. They are not magic. They still need human judgment at the critical moments. The goal is to make sure humans are only spending time at those critical moments, and not on everything else.

What This Means for Developers and Teams

One of the most honest parts of the conversation was when Krish noted the obvious: if Refound AI can provide software services without traditional developers on payroll, something structural has changed.

Sid agreed, but pushed back on the catastrophist framing. The role is not disappearing — it is shifting. Boris Cherny, the creator of Claude Code, put it plainly when someone pointed out that Anthropic keeps hiring engineers despite claiming 99 percent of its code is AI-generated. Cherny’s response: the work of engineering now looks a lot more like technical product management. It is about translating business requirements into precise instructions that allow AI systems to produce the right output — not writing every line yourself.

You still need to understand how code works. You need to make architectural decisions. You need to know how to evaluate what the AI produces and whether it makes sense. The craft is still relevant — it just expresses itself differently now.

Sid also raised a point about design that tends to get overlooked. Language models default to the average. They produce outputs that are generically competent but rarely distinctive. A person with a genuine sense of taste — not just visual design, but how interactions should feel, how an agent should behave, how a workflow should flow — is increasingly rare and increasingly valuable precisely because AI cannot reliably replicate it.

Where to Start

If you take one thing from this conversation, make it this: before you build, audit.

Before you pick a tool, spend a week having honest conversations with the people on your team about where their time actually goes. Ask them what they hate doing. Ask them what takes longer than it should. Ask them what they would eliminate if they could. The answers will tell you more about where AI can help than any vendor demo.

From there, the path is clearer than it looks. Identify the highest-leverage bottleneck. Build or commission a custom agent designed around your actual workflow and context. Keep a human in the loop at the moments that matter. Measure the time recovered. Then do it again.

Going AI-native is not about replacing your team with robots. It is about freeing your team from the work that was never really theirs to begin with — and giving them more time to do the things that only they can do.

Sid Bharath is the founder of Refound AI, an AI consultancy helping companies build AI agents and AI operating systems. Krish Palaniappan is the founder of Snowpal, a product and API platform. This article is adapted from their conversation on the Snowpal Podcast.

AI + Snowpal API: Reduce Time to Market

Podcast

AIOps: Turning Data into Action — on Apple and Spotify.

The AIOps Pipeline Diagram

Raw telemetry from across a hybrid IT estate flows into a unified data lake, where AI reasons over it to surface only what matters — routing each insight to either a human engineer or an autonomous remediation agent.

Q & A with Michael Nappi

1. What is AIOps and how does it differ from traditional IT operations?

AIOps extends traditional IT operations by applying AI/ML techniques to large volumes of telemetry data (metrics, logs, events, traces) generated across complex IT environments. While traditional IT ops relies on rule-based monitoring and manual intervention, AIOps enables automated correlation, noise reduction, anomaly detection, and actionable insights, helping teams understand system behavior and respond faster.

2. What core problem does IT operations aim to solve?

IT operations ensures that an organization’s compute, storage, and networking infrastructure runs reliably, efficiently, and continuously delivers services to the business. This includes maintaining uptime, performance, and availability while minimizing disruptions.

3. Who are the primary customers of AIOps platforms like ScienceLogic?

The primary customers are large enterprises, global 2000 organizations, government agencies (including DoD and civilian sectors), and MSPs. These customers typically operate large-scale, hybrid, and distributed IT environments requiring centralized visibility and control.

4. What role do MSPs play in this ecosystem?

MSPs manage IT infrastructure on behalf of other businesses, providing services like monitoring, incident detection, and remediation. They abstract operational complexity for their clients and are accountable for maintaining service availability and performance.

5. What value does ScienceLogic provide to MSPs and enterprises?

ScienceLogic provides a unified observability and operations platform that discovers infrastructure, aggregates telemetry, correlates signals, identifies issues, and enables both guided and automated remediation, effectively replacing multiple fragmented tools with a single system.

6. How does infrastructure discovery work in such platforms?

The platform detects all assets within an IT environment (anything with an IP address), including servers, network devices, applications, and services, using protocols like SNMP, SSH, APIs, and others. This creates a comprehensive, real-time inventory of the IT estate.

7. What are collectors and why are they used?

Collectors are lightweight Linux-based agents deployed within a customer’s environment that gather telemetry data locally and forward it to the central platform. They act as edge caches, improve resiliency, support secure communication behind firewalls, and enable operation in restricted or air-gapped environments.

8. Why not collect all data directly from the cloud without collectors?

Collectors provide architectural benefits such as reduced latency, improved reliability via store-and-forward mechanisms, compliance with security constraints (e.g., firewalls, air-gapped systems), and efficient data filtering before transmission, which is especially important in sensitive or distributed environments.

9. What types of data are collected and analyzed?

The platform ingests metrics, logs, events, and traces from infrastructure and applications. This telemetry may originate from cloud services (e.g., AWS CloudTrail), APIs, or system-level monitoring and is normalized and correlated for analysis.

10. How does the platform handle noisy or high-volume data?

It uses filtering, sampling, and intelligent ingestion strategies to avoid overwhelming the system with unnecessary data, focusing instead on meaningful signals that contribute to actionable insights.

11. Is the platform cloud-agnostic and how does it support multi-cloud environments?

Yes, it is fully cloud-agnostic, capable of monitoring workloads across AWS, Azure, GCP, on-prem systems, and virtualized environments, providing a unified “single pane of glass” view across all environments.

12. How is the platform deployed and hosted?

It can be deployed on-premises, hosted by ScienceLogic as a SaaS offering, or deployed within a customer’s or MSP’s cloud environment. The architecture is flexible to support various operational and compliance needs.

13. How does onboarding work for MSPs and their customers?

ScienceLogic provisions and configures the platform for MSPs in a SaaS environment. MSPs then onboard their customers into a multi-tenant system by deploying collectors, configuring integrations, and assigning user roles.

14. How does the platform model services instead of just infrastructure?

It maps underlying infrastructure components (servers, databases, APIs, etc.) to business services, enabling visibility into service health, performance, and risk. This allows teams to understand not just system status but business impact.

15. How does AIOps enable proactive rather than reactive operations?

By analyzing trends and patterns in telemetry data, the platform can detect early warning signs of degradation, predict potential failures, and alert teams before issues impact services, enabling proactive remediation instead of reactive firefighting.

Tanvi Mittal (GitHub) has spent over 15 years in software quality — starting as a developer, moving into test automation, and now sitting at the sharp edge of a field being fundamentally reshaped by AI. In a recent conversation on the Snowpal Podcast, she offered a candid, street-level view of what’s actually happening inside engineering teams today.

AI + Snowpal API

Podcast

A conversation with Tanvi Mittal, AI Systems & Quality Engineering Expert — on Apple and Spotify.

The Speed Problem No One Is Solving

The shift is striking. AI coding tools have dramatically compressed development timelines, but quality assurance hasn’t kept pace. “The ship to production has increased because now we have a lot of tools which we can leverage to code faster,” Tanvi observed. “But that has not been taken care of so seriously compared to the development part of it.”

In other words: teams are shipping more, but not necessarily testing more. If a sprint that once yielded 10 features now yields 30, the test coverage isn’t automatically tripling with it. That gap — between velocity and validation — is one of the defining challenges of modern software development.

The Tester Is Not Disappearing — But the Job Is Unrecognizable

Ask Tanvi whether the role of the manual tester still exists, and she’ll answer without hesitation: it’s “going super fast.” The person who walks through UI screens page by page, checking boxes manually, is largely a relic. In its place is something harder to define but far more demanding.

The industry is converging on what she calls full-stack quality: developers writing their own functional tests, and QA engineers shifting their focus to end-to-end integration, cross-system behavior, and — increasingly — AI-specific testing. “We definitely need a lot of quality checks around that,” she said. “I don’t see that QA is going anywhere soon.”

What is changing is the nature of the work. QA teams at large enterprises are now expected to be the first responders when something breaks in production. They’re digging through logs, tracing root causes, and managing the complexity of systems where dozens of services interact. That’s a very different job from checking if a button works.

Testing AI Is Not Like Testing Anything Else

Here’s where the conversation gets genuinely new territory. When the thing you’re testing is itself an AI — an agent, a chatbot, a decision-making system — traditional test cases stop making sense.

“The outputs can be different,” Tanvi explained, “but the gist of the work done by that agent should be the same.” You can’t write a test that expects a single, deterministic output. Instead, you’re validating behavior: does the agent do what it’s supposed to do, across a wide range of inputs, without doing what it’s not supposed to do?

That second part is where prompt injection comes in — the AI equivalent of SQL injection. A well-designed financial chatbot, for instance, should calculate loan payments. It should not be coaxed into writing Python code for a user just because they asked nicely. “If it’s giving me that, then it’s unnecessary use of tokens,” Tanvi noted, “and all those kinds of testing and data validation needed to be done.”

This kind of behavioral testing requires a fundamentally different mindset. It’s less about deterministic pass/fail and more about probabilistic trust: does this system behave reliably and safely, at scale, over time?

AI-Generated Code Still Needs Human Eyes

One of the more nuanced points Tanvi made is about the limits of trusting AI-generated tests. When an AI tool auto-generates 100 test cases alongside the code it writes, around 30 of them may be useless — technically invalid in the real production environment, or simply missing the edge cases that matter.

“You are not spending time on writing the code yourself. You are spending time to iterate through the code what is written by the AI and then updating that based on where it is not correct.” The same applies to tests.

This is a subtle but critical insight. The role of the QA engineer isn’t going away — it’s being elevated. The new job is judgment: knowing which tests are real, which edge cases an AI missed, and where the system’s behavior might diverge from expectation in the wild.

Governance, Observability, and the Rogue Agent Problem

As AI agents get more authority — taking actions, making decisions, operating autonomously inside complex systems — the stakes for getting testing wrong go up dramatically. A rogue AI agent might cause significant damage before anyone notices.

Tanvi’s answer to this is observability. Her focus has shifted toward log monitoring and production behavior analysis: catching anomalies early, before they become incidents. She’s even built an open-source tool called Log Miner to support this kind of proactive monitoring.

Tools like Datadog play a central role here — not just as passive log aggregators, but as active early-warning systems. Teams set custom alerts, monitor dashboards in real time, and treat unusual patterns as signals worth investigating before customers notice. “Before the customer points it out, there are a lot of checks and monitoring happening where you can figure out and change before it goes out of your control.”

Interestingly, she also flagged a gap: QA teams are rarely involved early enough in what gets logged and how. If logs are poorly structured, too noisy, or missing key traceable information, debugging production issues becomes exponentially harder. That’s starting to change — QA engineers are increasingly being brought into conversations about logging standards, not just the applications themselves.

FinTech Moves Slower, and For Good Reason

One of the more grounding moments in the conversation was Tanvi’s pushback on the narrative that AI is visibly transforming every software product. In regulated industries like banking and healthcare, that’s simply not what’s happening on the surface.

“FinTech is a sector where AI is not able to show a lot of impact because we have a lot of constraints,” she said. The improvements are real, but they’re mostly invisible to end users: faster deployment pipelines, automated backend processes, modernized APIs. A deployment that once took four to five hours now happens in two clicks. That’s meaningful progress — but you wouldn’t see it from your banking app.

The implication is important: the “AI is changing everything overnight” narrative is largely true for startups and smaller companies, not for enterprises operating in regulated spaces where trust, compliance, and stability rightly slow things down.

The Skill That Matters More Than Any Other

Near the end of their conversation, Tanvi was asked what she’d look for when hiring today that she wouldn’t have looked for two or three years ago. Her answer was unambiguous: prompt engineering.

“How good (they are) at prompt engineering — that is the one thing.” Combined with attitude and genuine dedication to the work, that’s the hiring filter she’d apply now.

It’s a telling signal. The ability to communicate precisely with AI systems — to construct clear, bounded, effective prompts — has become a professional skill, not just a party trick. It’s now table stakes for anyone working in or around software development.

Change Is the Only Constant (And Most People Are Lagging)

Perhaps the most honest thread running through the conversation was about the gap between what people say and what they actually do. Most parents — including Tanvi — are rethinking what success looks like for their kids in an AI-shaped world. Most professionals acknowledge that the skills needed to stay employable are shifting fast.

And yet. The same two-week sprints. The same college applications. The same job searches for traditional roles.

“We are in a world where every day we have to learn new stuff to be accommodating with the technologies shifting,” Tanvi said in her closing. “That’s it. We are learners every day.”

It’s a simple statement, but it cuts to the heart of what’s being asked of everyone in this industry right now — not just QA engineers. The people who will navigate this era well are the ones who treat learning not as a phase, but as a permanent condition of professional life.

Q&A with Tanvi Mittal

Q: Can you tell us a little about your background?

I have 15-plus years of experience in software. I started as a developer, then moved into quality engineering, working closely with large enterprises to build automation frameworks and test React and Angular-based applications. More recently, I’ve been focused on the AI side — how AI and AI agents are affecting software, and how we can carefully test them without leaking bugs into production.

Q: How has testing fundamentally changed with the rise of AI tools?

The biggest shift is that code is being shipped to production much faster because developers now have powerful tools to write code quickly. But the investment in testing hasn’t kept pace with that acceleration. If a lot of code is being generated in one week but we don’t allocate enough capacity for testing, that’s a serious gap. Speed without quality is a risk.

Q: Is the manual tester — someone who walks through UI pages by hand — still a relevant role?

That role is going away very fast. We’re moving toward what I’d call full-stack quality, where testers are also developers and developers are also testers. In smaller teams, that’s already the norm. In large enterprises, the shift is happening now. The QA focus is increasingly on end-to-end integration testing — where many systems interact — rather than checking individual pages manually.

Q: So is QA as a profession disappearing?

Not at all. The need is evolving, not shrinking. We now need people who can intelligently validate the behavior and output of AI agents and LLMs. That requires a very different skill set than traditional testing — but it’s very much in demand. I don’t see QA going anywhere soon.

Q: How do you test code that wasn’t written by a human?

For traditional software, we run it through the same test cases we’d apply to human-written code — plus a quality check on the generated code itself. For AI agents, it’s different. You’re doing behavioral testing: given a wide range of inputs, is the agent producing outputs that are consistent with its intended purpose? The outputs may vary, but the underlying behavior should be reliable.

Q: Can you explain prompt injection and why it matters for QA?

Prompt injection is to AI agents what SQL injection is to databases — it’s a way of manipulating a system into doing something it shouldn’t. For example, imagine a financial chatbot designed only to calculate loan payments. If a user can prompt it into writing Python code or revealing system instructions, that’s a security failure. Part of our job is to test that agents stay within their intended boundaries, no matter how creatively users phrase their requests.

Q: AI tools can auto-generate test cases alongside the code. Does that eliminate the need for human testers?

Not yet. In my experience, if an AI generates 100 test cases, around 30 of them may be impractical or invalid in a real production environment, and it often misses important edge cases. You still need a human to evaluate which tests are meaningful and which aren’t. The time saving is real — but the judgment required to use AI-generated tests responsibly still belongs to a person.

Q: How does QA fit into faster delivery cycles? Are two-week sprints still the norm?

In large enterprises, two-week sprints are still common. QA joins on day one — we sit with developers, understand what’s changing, assess the impact on other systems, and begin defining test cases. By day three we’re refining those cases. Developers handle about 80% of test automation, and our team focuses on the integration and end-to-end layer — making sure all the systems that touch the change are working together correctly.

Q: How are you seeing team structures change?

In startups, the change is dramatic — one person often covers product, development, and QA. In large enterprises, the shift is more gradual but visible. Product owners are managing three products instead of one. QA engineers are being asked to handle DevOps tasks like deployments and root-cause analysis. The days of narrowly defined, single-skill roles are fading. Everyone has to wear multiple hats.

Q: What does good AI governance look like in practice?

Observability is the foundation. You need to monitor production logs continuously so that when something goes wrong with an AI agent, you catch it before customers do. I built an open-source tool called Log Miner for this purpose. Tools like Datadog are central to this — you set up custom alerts, watch dashboards in real time, and treat anomalies as early warning signals rather than waiting for incidents to escalate.

Q: Why does FinTech seem slower to adopt AI visibly?

Because trust is everything in financial services. The customers’ data and money are on the line — that creates a high bar for introducing AI. A lot of progress is happening, but it’s behind the scenes: API modernization, automated deployments, internal tooling. Things that dramatically improve velocity for engineering teams but aren’t visible to the end user. That’s appropriate caution, not stagnation.

Q: Is a college degree in software still worth pursuing?

Honestly, it’s complicated. For fields like medicine or law, formal education is non-negotiable. For software engineering, the diploma is less critical than the skills — and the skills needed are changing faster than most curricula can keep up with. Personally, I wouldn’t push my kids toward software development the way previous generations were pushed. I’d want them to understand AI, not just code. That said, from a cultural standpoint, many families — including mine — haven’t fully made that mental shift yet.

Q: Are laid-off workers turning to entrepreneurship?

Most people are still looking for stable employment first. Business is not easy money — anyone who’s run a company knows that. Most people won’t leave a job until their business is already generating revenue. If someone gets laid off without a business plan, their first instinct is to find another job. Entrepreneurship tends to be the second choice, not the first.

Q: What’s the one skill you’d look for in a new hire today that you wouldn’t have cared about three years ago?

Prompt engineering. How well someone can communicate with AI systems — constructing precise, effective prompts — is now a core professional skill. Beyond that, I look for attitude: commitment, adaptability, and genuine dedication to the work. Those qualities matter more than ever in a world where the tools change every few months.

Q: Any final advice for people navigating this shift?

We are in a world where you have to learn something new every single day to keep up with how fast technology is moving. The people who will thrive aren’t necessarily the most experienced — they’re the most adaptable. Treat learning not as something you did in school, but as a permanent part of how you work.

Tanvi Mittal is an AI systems and quality engineering expert specializing in testing, reliability, and security in LLM-powered applications. This article is based on her appearance on the Snowpal Podcast, hosted by Krish Palaniappan.

Hydraulics — the technology that powers excavators, military vehicles, oil rigs, and factory floors — have been around since the 1800s. They work by pressurizing fluid to create force. They’re powerful. They’re proven. And according to Hiten Sonpal, CEO of RISE Robotics, they’ve hit their ceiling.

Hiten joined the Snowpal Podcast to talk about what his company is building, what he’s learned from shipping over 9 million units at iRobot, and why he raised $5.7 million from the crowd instead of from VCs. It’s a conversation worth your full attention.

Build Apps in Quick Time

Podcast

The Belt Revolution: How One MIT Startup Is Replacing Oil With Ingenuity - on Apple and Spotify.

The thing Rise Robotics actually built

Rise’s core technology is called Beltdraulic™ — and the name tells you most of what you need to know.

They took a hydraulic actuator (the cylinder that creates linear motion in heavy machinery), removed all the fluid, and replaced it with high-performance belts — the same kind used in elevators.

That swap sounds simple. The results are not.

Beltdraulic™ actuators are:

• 3× more efficient than hydraulics

• 3× faster

• 3× more durable

• Fluid-free — no leaks, no environmental contamination, no hydraulic oil fires

• AI-ready out of the box — they know their exact position, orientation, and load at all times

That last point matters more than it might seem. We’ll get back to it.

Who’s buying it

Rise has two primary customers right now: the Pentagon and the oil and gas sector.

The military angle makes intuitive sense. Soldiers working around traditional hydraulic equipment deal with diesel smoke, constant noise, and bases that eventually become environmental superfund sites from hydraulic oil leaks. Beltdraulic™ eliminates all of that. The Air Force and Army are already running programs with Rise focused on field readiness and reducing logistical complexity.

The oil and gas angle required more strategic thinking.

When Hiten joined Rise, the engineering team was excited about construction. Excavators, cranes — big, obvious applications. But construction moves slowly. The pain isn’t acute enough. Potential customers would hear the pitch and say: “Yeah, that sounds nice. Our customers aren’t really complaining though.”

Oil and gas was different.

Hydraulic systems in O&G run 24 hours a day, 7 days a week. Any downtime is expensive. Any leak is a liability. Any inefficiency compounds across years of continuous operation. Rise is now running pilots converting hydraulic natural gas pumps to belt-draulic ones — in a sector with an $11 billion addressable market, with oil pumps next on the roadmap.

“Our biggest enemy, since we don’t have any competitors, is inertia.”

— Hiten Sonpal

The lesson he took from this: don’t sell better. Find someone who’s in pain, and solve the pain.

What 9 million shipped units taught him

Before Rise Robotics, Hiten spent years at iRobot, leading teams that generated over $2 billion in revenue across 20 product lines.

The single most important thing he learned:

Every improvement you make costs exponentially more than the last one.

Whether you’re trying to cut cost, improve durability, increase speed, or extend battery life — each incremental gain takes more effort than the one before it. Start trying to improve five things at once, and you’ve built a project that won’t survive the next company reorganization.

His rule: pick three customer pain points, and only three.

Not the three coolest problems. The three problems your customer is loudest about, that no one else has solved, that you can actually ship a solution to within your runway.

For hardware companies, that runway is typically 18–24 months. For AI/SaaS, maybe 6–9. The timescale changes by industry. The principle doesn’t.

“You need to find out where your customer’s pain points are — and deliver a solution before the organization loses patience or you run out of money.”

This isn’t a compromise. It’s how you stay in the game long enough to solve the hard stuff later.

Why Beltdraulic™ and AI belong together

Here’s the AI angle that most people in the robotics space are underestimating.

Traditional hydraulic systems have what engineers call bang-bang control — you open a valve, fluid moves, something pushes. You don’t know exactly how far it moved, how much force it applied, or where it stopped without a separate sensor system. Closing that loop requires a trained human operator in the seat.

Belt-draulic actuators are different. Every actuator knows, at all times:

• Its exact position

• The forces it’s experiencing

• Its orientation

That’s a digital twin out of the box. And a digital twin is the foundation for everything autonomous: remote operation, semi-autonomy, full autonomy, predictive maintenance.

Hiten drew a comparison to the self-driving car industry. Meaningful autonomy didn’t arrive until vehicles switched to drive-by-wire — electronic control replacing mechanical linkages. Every serious autonomous vehicle platform had to make that switch before the AI could actually take over.

The same transition is coming to heavy equipment. Beltdraulic™ is the drive-by-wire layer for excavators, forklifts, military vehicles, and oil rigs.

The data angle is equally compelling. An actuator that knows how hard it’s working can tell you when a part is being overstressed — years before it fails in the field. It can tell you if a customer is consistently lifting half their rated load (maybe they’re over-engineered and overpaying). It can generate evidence for carbon credit claims after switching away from hydraulics.

The crowdfunding twist

When Hiten joined Rise, the VC market wasn’t interested on good terms. Everyone wanted humanoid robots and AI. A deep-tech industrial hardware company didn’t fit the narrative.

But Rise had 1,500 LinkedIn followers who kept asking how they could get involved.

Hiten noticed that, and remembered something: Regulation Crowdfunding — a law passed during the Obama administration — allows startups to raise up to $5 million from the public in a 12-month window, offering real equity, not just perks.

He ran a “testing the waters” campaign to gauge interest. Within a month: $800,000 in soft commitments.

So they launched a full campaign on WeFunder, the world’s largest crowdfunding platform.

The result: $5.7 million in reservations — $700,000 more than the legal cap. Rise had to turn money away.

A few things made it work:

The terms were the same as their institutional round. Third-party ratings firm King’s Crowd gave them 4.7 out of 5 stars specifically because retail investors were getting institutional terms — something almost unheard of in crowdfunding.

The investor base is strategic, not just financial. Rise now has 2,500 investors who introduce them to customers, suppliers, and future investors. Some are active military or veterans who work with hydraulic equipment and want to see it improved. Some are climate-focused. Some are just smart retail investors who’ve realized that the best returns in companies like SpaceX were captured long before any IPO — and they want in earlier.

The minimum investment is $250. Anyone can participate.

Hiten is opening another round to accommodate the $700K that didn’t fit last year.

The bottom line

Rise Robotics isn’t trying to build a humanoid robot or solve general AI. They’re solving a specific, expensive, widespread problem that has existed for a century — with technology they can manufacture today, deploy in existing equipment, and scale through a market worth three-quarters of a trillion dollars.

The strategy is clear: go wide until you find a vertical where the pain is acute, then go deep. Focus on three things. Ship. Repeat.

If you’re a founder, there’s a product development framework here worth stealing. If you’re an investor, there’s an opportunity worth looking at seriously — especially before the next institutional round.

Q&A with Hiten Sonpal

Q: Give us a quick intro — who are you and what does Rise Robotics do?

I’m the CEO of Rise Robotics. I’ve been with the company for less than two years, brought on board by the founders to help take the company to its next stage of growth — primarily through commercialization of their technology. The company is affiliated with MIT; three out of four founders went to school there.

What we do is build a new kind of linear actuator that replaces hydraulic systems. We call our technology belt-draulics. We’ve taken the oil out of hydraulic systems and replaced it with modern belts — the same kind used by the elevator industry. By doing that, we’ve created a technology that’s three times as efficient as hydraulics, three times as fast, three times as durable, and is AI and automation-ready out of the box.

Q: Who are your customers right now?

Our biggest customers currently are the Pentagon — specifically the Air Force and the Army. We’re developing hydraulic-free solutions to help improve their readiness and reduce the logistical footprint they deal with in the field.

We recently started commercializing our technology commercially. Our first commercial sale was in the second half of last year — a pilot in the oil and gas sector, which has an $11 billion addressable market. We’re converting hydraulic natural gas pumps to belt-draulic ones, which are completely fluid-free. After that, our next step is oil pumps. Further down the line we’re looking at construction, forestry, and maritime. We have a lot of interest from heavy industry in general, but those are our two primary customers right now.

Q: Do you have competitors?

We actually have no competitors in the traditional sense. Our competitors in one way are the incumbents — companies currently making hydraulic systems — but they’ve reached the ceiling of the S-curve in terms of what can happen with fluid-based actuation.

There are also companies that make linear actuators using screw-type technology — taking a ball screw and rotating it to push forward and backward. Those companies are more likely to be our partners than our competitors. Their stroke lengths are relatively small, their speeds are slow, and the forces they can apply are limited. We have longer stroke lengths, higher speed, and higher forces. We’re very complementary to screw-type actuators. So basically, we don’t have any direct competitors in this space.

Q: What has building deep tech taught you about product development?

The key insight for me came from my time at iRobot, where teams I led generated over $2 billion in revenue and shipped over 9 million units across 20 product lines.

What I learned is that when you’re trying to improve performance in any one axis — cost, reliability, speed, durability — the effort required increases exponentially with each increment. When teams try to tackle multiple axes at once, all those exponentials stack up very quickly. At some point the problem becomes intractable.

Most large organizations reorganize every 18 months. If your project isn’t making substantial traction, it won’t survive two reorganizations. The same is true for startups — 18 months of runway means you need milestones.

So my key insight has been to help engineering teams understand they don’t have to solve everything. Pick three key problems the customer doesn’t have a solution for, and focus on delivering those. If you can solve those three things, you’ll have a market and a successful product. Think of a spider chart with all these axes — how do you squish that chart down to something tractable within a given timeframe?

Q: How do you stay focused on those three things when the world keeps changing?

The timeframe needs to be sized to the rate of change in a particular industry. In consumer electronics, 18 months is right. For pure SaaS, maybe 9 months. For AI-driven companies, even 6 months. For heavy industry, maybe 24 months.

But the core tenet still holds: can you find your customer’s pain points and deliver on them before the organization loses patience or you run out of money?

The world is changing quickly — it is possible that while you’re pursuing those three pain points, something shifts. But keeping that focused tempo means if one thing changes, you still have two to work with. If you were trying to solve ten things, a third of them shifting throws away a massive amount of work. Focusing on a few things and getting them right works across sectors, across industries, whether it’s software or hardware.

Q: How do you bring hardware innovation into legacy industries? What’s the biggest challenge?

Our biggest enemy — since we don’t have any competitors — is inertia. Legacy industries have been doing things a certain way for a very long time. Their training, their processes, their entire operation has been optimized for the technology they already have. Bringing change is very challenging.

What I’ve found works well is identifying customers who have a specific pain point that really bothers them — and going to address that pain point directly. That causes industries to move. If we show up and say ‘this is better,’ it takes a long time to get traction. But if we show up and say ‘we can solve this particular problem you’ve been living with,’ that’s different.

When I first joined Rise, the engineering team was excited about construction. It’s a large market — but it’s slow moving. Customers there would say ‘yeah, this sounds nice, but our customers aren’t really complaining.’ Oil and gas was different. Hydraulic systems there run 24/7. Any durability problem, efficiency problem, or downtime is substantial. By shifting to a customer with a real pain point, we got more traction immediately.

Q: Did you go horizontal or vertical in your market approach?

We started horizontal, which made sense when I joined. We launched our second-generation cylinder — the first standalone unit we could actually ship — at Bauma in Germany, the world’s largest construction show. We had over 200 leads from that show, across construction, agriculture, distribution, and more.

When we came back, we evaluated all of them — understanding the problems of each, where we were as a company, and which customers could meet us where we are. When we discovered the oil and gas vertical, it became very clear that going broad had been the right move to find it. Once we identified a vertical that was compelling, we could stop going broad and go deep.

So the approach was: start horizontal until you find a vertical where the pain is acute and the margins are good, then commit. We still take joint development opportunities from customers in other sectors who come to us, but when it comes to where we put our own chips — we’re going vertical.

Q: Are your products AI-native, or do they work without AI?

We are AI enablers. We don’t have AI inside the actuators, and our customers don’t need AI tools to build a drive-by-wire system using our technology.

But if they choose to add semi-autonomy, teleoperation, or full autonomy, our systems enable all of that — without depending on it. The reason is that our actuators provide precise multi-position control out of the box. You know the position of every actuator, the forces it’s experiencing, and its orientation at all times. That’s a digital twin out of the box, which is the foundation for everything autonomous.

Traditional hydraulics have what’s called bang-bang control — you open the valve, the fluid moves, and you don’t have precise feedback. You need a trained human operator in the seat to close all those loops in their head. With our technology, an AI system gets everything it needs for a digital model — and you can implement safety policies that are mathematically calculated, not statistically guessed.

Q: How does your technology relate to the autonomy transition we’re seeing in vehicles?

The analogy to autonomous vehicles is almost exact. Meaningful autonomy at scale didn’t arrive until manufacturers switched to drive-by-wire platforms. Companies like Waymo and Hyundai couldn’t truly scale autonomous systems until the vehicle’s mechanical controls were replaced with electronic, software-addressable controls.

The same transition is coming to heavy equipment. As long as excavators, forklifts, and industrial machines rely on hydraulic systems, full autonomy remains out of reach. Our technology converts those hydraulic systems into drive-by-wire systems — which is the foundational layer that any autonomous or AI control system needs.

Waymo has even revealed they use remote operators in the Philippines and the US to help get Waymos unstuck from corner cases. The only reason that’s possible is they have a full digital model of the car and its environment. With a hydraulic excavator, that kind of remote situational awareness simply doesn’t exist.

Q: What do startups typically get wrong when scaling complex technology?

The most common mistake is trying to optimize across too many dimensions at once. Teams want to cut cost AND improve reliability AND increase runtime AND improve durability — all at the same time. Each of those improvements is exponentially harder than the last, and when you stack them all together, you’ve built something that can’t be delivered in the time you have.

The discipline required is brutal prioritization. You have to help your engineering team understand that they don’t need to solve every problem — only the three that the customer is actually crying out for. And you need to be honest about your timeframe. Whether it’s 9 months or 24 months, you have a clock. The project that survives is the one that ships something real within that window.

The second mistake is not finding customers early enough. We’re a B2B company, and the instinct in deep tech is to stay in the lab until the technology is perfect. But customer pull is what actually tells you which problems are worth solving — and it’s what gives the organization a reason to keep funding you.

Q: Tell us about your crowdfunding approach — what is Regulation Crowdfunding and why did you use it?

When I joined Rise, the VC market wasn’t offering us great terms. Investors were chasing humanoid robots and AI, and our terms as a deep-tech hardware company were unattractive.

But we had 1,500 LinkedIn followers who regularly asked how they could get involved. That gave me an idea. I was advising a couple of companies that had successfully raised using Regulation Crowdfunding — a law passed during the Obama administration that allows startups to raise up to $5 million from the public over 12 months, with real equity.

We ran a ‘testing the waters’ campaign first — people could express interest without committing money. Within a month we had $800,000 of interest. So we launched a full campaign on WeFunder, which is the number one crowdfunding platform in the world. To our surprise, we ended up with $5.7 million in reservations — $700,000 more than the legal cap. We had to turn money away.

What we didn’t expect was how strategic those investors would become. We now have 2,500 investors who introduce us to customers, suppliers, and future investors. Some want to be customers themselves. It’s been extraordinary.

Q: Do investors in your crowdfunding campaign get real equity in Rise Robotics?

Yes — the process has advanced significantly over the past few years. What happens is that an LLC ends up owning a chunk of the company. All the crowdfunding investors own a piece of that LLC. So it’s very straightforward equity ownership — just structured with one layer so that our cap table doesn’t get unwieldy.

This way we have one line on the cap table representing our 2,500 investors, which institutional VCs are comfortable with for future rounds.

We can also take very small checks — the minimum investment in Rise Robotics is $250. Anyone can participate. And one of the reasons our campaign had so much traction is that the terms we offered retail investors were the same terms we offered institutional investors. The ratings firm King’s Crowd gave us 4.7 out of 5 stars specifically because of that.

Q: Who else is investing in Rise, beyond just technology enthusiasts?

We’re getting three distinct types of investors. First, there are impact investors — people in the armed services who work with hydraulic equipment and see firsthand what belt-draulics could do for soldiers. With our tech, they can stop inhaling diesel smoke, stop being around loud equipment that damages hearing, and stop dealing with hydraulic oil leaks that eventually turn military bases into environmental superfund sites. Those people invest because they believe in the mission.

Second, there are climate-focused investors who like the clean energy angle — removing fluid leaks and improving energy efficiency across heavy industry at scale.

Third, there are savvy retail investors who are starting to think like VCs. They look at our $750 billion addressable market, see that we’re disrupting something real, and recognize that companies like SpaceX are going to IPO at $1.5–2 trillion — meaning most of the money has already been made by the time a retail investor could buy in. Reg CF gives retail investors the chance to get in early, on institutional terms.

Interested in Rise Robotics? Visit riserobotics.com or explore their investor campaign at invest.riserobotics.com.

Listen to the full episode on the Snowpal Podcast.

Want to Invest in RISE Robotics?