Why Building on “Markets Only Go Up” Is a Bad Product Assumption

I stopped treating rising markets as a default and the product got less fragile

One of the more expensive assumptions I baked into Hot Glue early on was that the market would keep going up forever, or at least long enough that I could ignore what happened when it didn’t. I didn’t say it that way in the code or planning docs, but that’s what the product logic implied. More user deposits, more transaction volume, more appetite for risk, more tolerance for messy onboarding, more willingness to try another AI-assisted finance workflow. When the market mood changed, a bunch of things that looked like product wins turned out to be bull-market artifacts.

I want to be concrete about this because “don’t assume growth” is too vague to be useful. What actually broke was prioritization. I built flows that only felt good when traffic, asset prices, and user optimism were rising together. The minute those conditions weakened, the product’s rough edges got much louder. Churn showed up in places I hadn’t instrumented. Messaging that converted in strong weeks looked borderline irresponsible in weak ones. A few automations that were fine for accumulation behavior became actively annoying during drawdowns because people wanted protection, visibility, and control, not another nudge to deploy capital.

The key mistake wasn’t being optimistic. It was using market direction as a hidden dependency in product design. Once I saw that clearly, I changed how I spec features, how I prompt AI when generating flows and copy, and how I evaluate whether something is truly useful or only useful when everyone’s portfolio is green.

Where the bad assumption showed up in practice

I build inside MakerWS with AI in the loop, so a lot of early product shaping happens through prompts, generated schemas, quick interface scaffolds, and automation drafts. That’s fast, which is good, but it also means your assumptions spread everywhere quickly. Mine spread into the database, notifications, dashboard defaults, and event logic before I’d really tested them.

One early prompt I used for a portfolio action feed was basically: create a dashboard that helps users put idle cash to work and surface opportunities based on momentum, recent deposits, and under-allocated positions. That sounds reasonable. It also encodes a worldview. The generated UI emphasized action over caution. It prioritized “next best move” cards, contribution nudges, re-entry suggestions, and asset-level upside framing. It had almost nothing for “what changed, what got riskier, what should I pause, what exposure am I accidentally increasing?”

That wasn’t the model being wrong. That was me prompting toward expansion because I was mentally anchored to an upward market. I accepted the generated structure because it matched the environment I happened to be building in.

The same thing happened in the data model. In one version of the account state logic, I tracked contribution streaks, funding cadence, and target progress, but downside context was thinner. I had tables for recurring actions and allocation targets, but not enough first-class state for drawdown-aware behavior. I had no strong notion of user intent changing under stress. The system knew a user missed a recurring contribution. It didn’t know whether they paused because they were nervous, because their cash flow changed, or because the market drop changed their risk tolerance.

That matters because product behavior follows structure. If your schema makes bullish behavior easy to detect and cautious behavior vague, you’ll build a bullish product even if you think you’re being neutral.

The first failure was copy that only worked in good conditions

I noticed the problem in generated copy before I fully understood it in the product. I was using AI to draft onboarding text, empty states, and alert messages. The prompts weren’t absurd. They were things like: write a confident, clear onboarding sequence for users automating long-term portfolio contributions. Or: generate supportive copy that reduces hesitation and keeps users focused on compounding. Again, not crazy. But when the market turned soft, that voice started sounding detached from user reality.

The output leaned hard into patience, discipline, and long-term conviction. Those ideas aren’t wrong, but the generated copy skipped over the emotional and operational state users were actually in. Some people weren’t hesitating because they needed encouragement. They were hesitating because they no longer trusted the assumptions behind the workflow. Others wanted less automation, not more reassurance. The product kept trying to get them back into the loop it had originally optimized for.

I rewrote the prompts after that. I stopped asking for “confidence” as a default tone. I started asking for messages that acknowledge uncertainty without becoming mushy. One improved prompt was closer to: write system copy for a user deciding whether to continue, reduce, or pause recurring contributions after a market drop; do not assume the best action is to keep buying; offer clarity on options and consequences. The output got less shiny and more useful immediately.

The prompt change looked small, but it changed the product stance from “keep moving” to “help me decide.”

The second failure was automation that confused market tailwinds with product fit

I had a period where a few automations looked stronger than they really were. Completion rates were good. Users accepted suggested actions at decent rates. Reminder sequences seemed to work. I initially read that as proof that the workflow design was solid.

Then I looked at behavior over a rougher stretch and the pattern changed. Acceptance dropped, but the more important signal was that users interacted differently with the same screens. They spent more time on visibility features, ignored “deploy” suggestions, and looked for pause controls and explanation text. In other words, the product had not earned broad trust. It had been carried by favorable context.

I had to separate “this works in a rising market” from “this solves a stable user problem.” Those are not the same thing. A bull market can make weak software look stronger because users are more forgiving when outcomes are positive. They’ll tolerate setup friction, imprecise recommendations, and half-baked analytics if the surrounding environment keeps validating them. You get fake confidence from external momentum.

Inside MakerWS, that showed up in the way I reviewed generated flows. I had been asking, does this sequence move the user toward activation? I changed the review frame to, does this sequence still make sense if the user is anxious, reducing exposure, or questioning the premise? That one question killed several features that had looked promising on a happy-path dashboard.

What I changed in the build process

I didn’t solve this with a manifesto. I changed files, prompts, event types, and acceptance criteria.

The files and logic that had to change

I don’t want to pretend this was abstract strategy work. It was mostly cleanup. In my workflow definitions, I had too many action-first assumptions. For example, a recurring investment workflow originally moved from scheduled check to funding confirmation to allocation suggestion with no serious branch for “user no longer wants this cadence under current conditions.” So I added explicit branches for skip, reduce, and review. That sounds like product copy, but it affected event handling and downstream messaging.

I revised state names in my config and handler files so the product stopped treating hesitation as failure. In practical terms, I changed things like pending_action and missed_contribution into states that distinguished non-response from deliberate pause. That let me avoid dumb follow-up behavior where the system kept pushing a user who had already signaled caution through another route.

I also changed dashboard composition. The first version ranked modules by likely actionability, which in reality meant “things that encourage movement.” I replaced some of that ordering logic with context-sensitive panels. If volatility or recent account behavior suggested a user was in assessment mode, I surfaced exposure summaries, recent changes, and control settings ahead of recommendation widgets. This wasn’t flashy. It reduced the number of times the interface felt tone-deaf.

The brittle part was that AI-generated scaffolds had made the initial direction easy to overextend. Once a dashboard and event pipeline exist, it’s tempting to keep layering logic on top rather than question the premise. I had to stop asking the AI to improve the existing growth-centric workflow and instead ask it to generate alternatives from a different assumption set.

The prompt pattern that worked better

The most useful change I made with AI was forcing scenario diversity into the prompt itself. Instead of asking for the best investing workflow, I started asking for a workflow that remains useful across at least three conditions: rising market, flat market, and falling market. I also asked the model to identify where the interface, automation, or copy would become harmful if it assumes continued appreciation.

That “where does this become harmful” clause was surprisingly effective. It made the model surface edge cases I had been filtering out mentally. Some examples it flagged were repetitive contribution nudges during steep declines, misleading progress indicators that looked positive only because target prices were stale, and simplified performance widgets that encouraged users to equate recent movement with strategy quality.

I also got better results when I asked the model to produce state machines instead of feature descriptions. “Design a user flow for recurring portfolio contributions” often produced a glossy growth flow. “Produce a state machine for recurring contributions with explicit user intent transitions under uncertainty, drawdown, and pause conditions” produced something much closer to what I could actually build safely.

Why this matters even outside investing products

The phrase “markets only go up” sounds specific to finance, but the product mistake generalizes. Any time you build as if favorable conditions will continue, you’re making the same class of error. It could be ad costs staying cheap, API pricing staying stable, AI latency staying tolerable, users remaining willing to hand over raw data, or teams continuing to accept low auditability because output quality looks good this month. If your product only feels good under tailwinds, it isn’t mature. It’s subsidized by context.

I saw a version of this in AI-assisted workflow generation itself. Early users are often generous because novelty carries part of the experience. They’ll forgive weird edges if the system produces something useful quickly. That’s not durable. As the novelty fades, people judge the system more harshly under failure, ambiguity, and rework. So if your product assumption is basically “users will stay impressed,” that’s another variant of “markets only go up.”

Hot Glue got better once I started building for unfavorable conditions as a first-order case rather than a fallback case. It made the product less charismatic and more dependable. I think that’s a good trade most builders avoid until the environment forces it.

The trade-offs were real

This change didn’t make every metric look better. Some activation paths became slower because I added decision points that acknowledged uncertainty. A cleaner growth funnel would probably have converted better in peak optimism windows. Some generated copy became less persuasive because it stopped pushing a single “smart” action. Some dashboards looked less exciting because I gave more space to controls and context instead of recommendations.

But those trade-offs were honest. Before that, I was effectively borrowing conversion from favorable sentiment. That’s not stable product performance. It’s market-assisted performance. Once I accepted that, I was more willing to ship interfaces that respected a user’s need to hesitate.

I also had to accept that resilience is harder to demo. An action-heavy workflow with upward assumptions looks great in a quick walkthrough. A workflow that says “here are your options, including pause and review” feels less magical. Still, the second one survives reality better. And when you’re building with AI, reality checks matter because generated systems can look finished long before they’re actually trustworthy.

A simple test I use now

When I review a new feature, prompt, or workflow, I ask one plain question: if the surrounding environment gets worse next week, does this still help the user or does it start pushing nonsense? If the answer is “it probably gets annoying” or “the copy becomes awkward” or “the recommendations stop making sense,” then I know the feature was leaning on external optimism.

I run this test on generated copy, state transitions, notification cadence, and dashboard ranking. Sometimes the fix is small, like changing a CTA from continue to review options. Sometimes it’s structural, like adding a new state and branch logic for reduced-risk behavior. Either way, the goal is the same. I don’t want product value to disappear when sentiment does.

• Can the user intentionally pause without being treated like they failed?
• Does the product explain changed conditions instead of only recommending action?
• Will the alerts still sound sane if the user is losing confidence?
• Is “do nothing for now” represented as a valid system state?
• Am I measuring product usefulness separately from favorable market context?

What surprised me most

The surprising part wasn’t that bad markets exposed weak assumptions. That part is obvious. The surprising part was how easily AI accelerated those assumptions into every layer of the build. If your prompt carries a hidden market belief, the generated schema, workflows, UI sections, and copy often reinforce it all at once. You get internal consistency around a bad premise, which can feel a lot like good design.

That’s why I now treat assumption checks as part of AI-assisted building, not as a separate strategy exercise. Before I ask MakerWS to scaffold a flow, I try to state the market or environment assumptions explicitly. If I can’t do that, I’m probably about to encode them by accident. If I can do it, I can ask the model to generate the opposite case too and compare them.

That simple habit has saved me from shipping a few polished dead ends. It doesn’t make the product perfect. It does make it harder for me to confuse a temporary tailwind with a durable product truth.

The build lesson I kept

I don’t build from “markets only go up” anymore, even when the trend looks strong and the data makes optimism easy. If a feature, workflow, or message depends on users feeling richer, braver, or less skeptical next month, I treat that as a risk in the design, not a bonus. That’s the useful hindsight here. Hidden assumptions about favorable conditions don’t stay hidden for long. They turn into defaults, then defaults turn into product behavior, and then the environment changes and your software starts arguing with your users.

Once I saw that happening in Hot Glue, the fix wasn’t dramatic. I changed the states, changed the prompts, changed the review questions, and let the product support caution without treating it as a bug. That made the whole system more honest. It also made it more likely to keep helping when the easy conditions disappear.