kajolshah_bt

I wrote this myself (Director at Budventure).

I keep getting asked: How much does a React Native app cost in the US? I wrote down the common price ranges and the reasons that usually change the costs. I also added a one-page PDF checklist you can download.

The checklist includes: - What to include in the first version (and what to skip) - How screens affect cost (logins, payments, maps, video, etc.) - Choosing Expo, and when you need to write your own code. - Backend and admin work people forget to count - Testing and app store release work - Ongoing monthly costs after the app launch (hosting, SMS, maps, analytics, crash reports) - Contract items that matter (source code access, change requests, ownership)

If you share your main features and any third-party services you need, I can tell you what parts usually get missed in quotes.

I think a lot of people push back on calling LLMs AI because the word means different things to different people. For many engineers, AI used to mean systems that can reason, adapt, and make judgments over time. LLMs don’t really do that. They’re very good at predicting the next word based on patterns they’ve seen before. That gap matters, especially to people who’ve watched tech hype come and go. There’s also a product side to this. When something is labeled AI, users expect understanding. What they often get instead is confidence without awareness. The system shows it's very sure, even when it’s guessing.

I’ve seen smart features break trust this way. Not because the model was bad, but because the product treated its guess like a final answer. Users don’t complain much when that happens. They just stop using it. So I get why people resist the label. It’s less about denying progress and more about avoiding false expectations.

The more useful question might be what kinds of decisions should these systems make on their own, and where should they stay in a supporting role?

The spending numbers are wild. More than the moon landing and we’re mostly using it to autocomplete emails and generate slide decks.

That doesn’t mean it’s useless. It just means the infrastructure is way ahead of the everyday experience.

What I keep noticing is that the big breakthroughs aren’t coming from bigger models. They’re coming from very specific product decisions.

Things like:

– Apps that understand context without you re-explaining everything

– Interfaces that predict what you need before you type

– Systems that remove 3–4 manual steps

That’s where the real shift is happening.

If all this spending just results in faster chatbots, the market will correct hard. But if it turns into software that genuinely reduces friction in daily work, then the long term value will be justified.

I wrote about this recently: what features will mobile apps need in 2026 if they don’t want to loose users. Most of it has nothing to do with flashy demos and everything to do with removing invisible friction.

Do others here think spending is ahead of product reality or if we’re underestimating what’s quietly being built?

I think you’re onto something.

Every time we blame the model, I wonder how much of it is just the system we dropped it into.

If you put anything, human or model, inside a loop that rewards fast feedback, visibility, and ranking, you’re going to get behavior that chases those signals. That’s not an AI problem. That’s how optimization works.

MoltBook feels less like AI went rogue and more like we built a sandbox that rewards noise.

We already ran this experiment with social media. Engagement became the metric = content optimized for engagement. No surprise what happened next.

Same with SEO. Same with crypto incentives.

So when we talk about alignment, I sometimes think we’re staring at the weights while ignoring the scoreboard.

If the scoreboard rewards short-term signals, agents will optimize for short-term signals.

The more interesting question to me is: what happens when you put these systems into environments with slower feedback loops? Long-term interaction, memory, correction, reputation.

That probably shapes behavior more than another round of fine-tuning.

I don’t think you’re missing anything. The hype cycle is real.

But I also don’t think the signal is zero. It’s just buried under capital and compute flexing.

The pattern I see isn’t AI is revolutionary. It’s: 1) The easy wins are done. 2) The marginal gains are getting expensive. 3) The distribution layer is shifting faster than the capability layer.

Most new model releases aren’t unlocking fundamentally new workflows. They’re compressing friction in workflows that already work. That’s useful, but not narrative-worthy.

The real shift isn’t GPT-5.3 vs GPT-5.2.

It’s: - AI replacing search as the interface layer. - AI compressing junior-level execution work. - AI reshaping how products are discovered (AI Overviews, summaries, agents).

That doesn’t make MoltBook any less absurd. Burning compute on bots talking to bots is peak theater.

But dismissing everything because of the theater might be like dismissing the internet because of Pets.com.

We may be at peak hype, but that doesn’t mean the substrate shift isn’t real.

The question isn’t, is AI overhyped? It’s, where is durable value forming?

That’s harder, and way less viral, to answer.

I see this split clearly in real products: some users treat AI like a tool to support their workflow, others treat it like a replacement for thinking. The first group uses AI to reduce repetitive work and interprets results critically; the second group abandons it when outcomes aren’t perfect.

In practice, the users who end up valuing AI are the ones who see it as an assistant, not an oracle. That distinction matters because it shapes how you design UI, fallback flows, and trust signals. If the interface assumes perfect output, retention drops; if it assumes collaboration with the user, retention improves.

I don’t think AI is killing B2B SaaS. It’s exposing what was already broken. A lot of legacy SaaS shipped features that never solved real customer problems; AI just makes that obvious because users now expect intelligence and responsiveness. The products that survive are the ones that use AI to solve actual friction points, not just add another automation toggle.

In our work, we’ve seen features like AI search and guided workflows improve retention only when they reduce manual effort and are trusted by users. If an AI feature feels like a gimmick, people ignore it. So I’d reframe it: AI is accelerating differentiation, not destroying the category.

That description matches a lot of what we’ve seen in real products. AI does make some parts of development and workflows easier like summarizing data, generating initial drafts, or auto-completing repetitive patterns. Those wins are real.

The hard part that becomes harder is not the technology. It’s the decision-making around it. When teams rush to integrate a model into core workflows without measuring outcomes or understanding user behavior, they end up with unpredictable results. For instance, we built an AI feature that looked great in demo, but in real usage it created confusion because users didn’t trust the auto-generated responses. The easy part (building it) was straightforward, but the hard part (framing it in a way people trusted and adopted) was surprisingly tough.

In real systems, success with AI comes not from the model itself, but from clear boundaries, human checkpoints, and real measurements of value over time.

I’ve gone through a similar journey, not in big tech, but in practical business work. We started with quick experiments: generative prompts in internal tooling, a couple of proof-of-concept bots, and integration of recommendations in mobile apps.

What shifted for us was when we stopped experimenting for novelty and started embedding AI where routine work slowed people down. For example, we built an intake assistant for hospitals: guided questions that organize structured history before a doctor sees the patient. At first it felt promising, but adoption only happened when clinic staff saw that it saved them time and didn’t replace their judgment. That forced us to rethink how we framed the feature. It became about support, not replacement.

The real adoption turning point came when non-technical team members began using the tools without hesitation. That’s when it stopped being AI and just became part of workflow.

Thanks for sharing your thoughts! I totally get where you’re coming from on notifications. It’s like apps that bombard you with prompts or notifications right away are almost disrespecting your time and focus. It really is about having apps that respect your attention and only interrupt when it’s truly necessary.

I love how you’ve shifted from needing constant reminders to building your own system to stay on top of things. I think that's something a lot of people can relate to. The idea of relying less on reminders and more on our own discipline.

It also reminds me of some of the newer trends I’ve seen in app development, like smarter notifications that are way more thoughtful about when to get your attention. I wrote a blog on how AI is helping mobile apps do just that, making notifications more useful without being a nuisance. If you’re curious, I shared a bit about it here: [AI Features in Mobile Apps for 2026 - https://www.budventure.technology/blog/ai-features-mobile-ap...]

This matches my experience pretty closely.

A lot of teams treat notifications as a default feature instead of something that has to earn its place. From the builder's side, it’s often framed as keeping users engaged, but from the user's side, it’s just another interruption competing for attention.

What I find interesting is that muting often just means I’ll use this when I need it. That often gets lost when teams look at notification opt-out as a negative metric.

This is a really helpful way to separate the two.

I think a lot of product discussions collapse engagement into notifications, when in reality many useful tools are pull-based by nature. I personally have apps I use weekly that would be worse if they ever notified me.

Maybe the mistake is assuming interruptions equal usefulness, when for many apps the value is exactly the opposite: being available, predictable, and quiet until needed.

This is really helpful. That matches what I’ve seen too, but you’ve explained it more clearly than most product docs ever do.

The part that stands out to me is how default notification prompts feel like an insult to intelligence rather than a value exchange. A lot of teams treat “turn on notifications” as a growth lever, when for users like you it’s already strike one.

Have you ever kept an app around without notifications because the pull was strong enough on its own? Or is the bar now basically “silent by default, prove value first?”

Trying to understand whether mute is more about notification behavior specifically or a broader signal that the app hasn’t earned ongoing attention yet.

Yes, exactly. A lot of demos just don’t fail in the real world. They were never designed for real usage in the first place. They work once, in a clean flow, and fall apart as soon as people behave… like people.

This is such a classic failure mode: even a 15–20% confident misroute is brutal because it forces “review everything,” kills trust, and increases repeats/reopens.

When you rolled back, did you keep AI as suggestions only + rules-based routing? And what metric exposed it fastest for you: recontact rate, handle time, or escalation to humans?

Totally agree — the “demo vs real world” gap is always the messy edge cases: accents, crosstalk, domain terms, and people talking like… people.

Did you end up adding any guardrails (confidence thresholds, “please repeat,” glossary/term injection, or human fallback)? Also curious: were failures mostly ASR or translation/context?

Strongly agree. In my experience, asking “what concrete action changes if this works?” filters out most premature AI ideas. If no one can point to a changed decision, AI just adds cost and complexity without leverage.

When the answer is vague (“better insights”, “faster responses”), AI tends to add surface polish without leverage. The projects that stick usually start with a very boring question: what specific action will someone take differently tomorrow?

I’ve seen AI help only after teams agree on workflows, data definitions, and success metrics. When those aren’t clear, AI often makes the confusion harder to notice. Curious if others have seen the same pattern.

I’ve seen AI help with COBOL only after the system is well understood. When specs are fuzzy or tribal knowledge isn’t written down, AI just produces confident but risky code. It speeds things up only once the basics are already clear.