DEV Community: Kajol Shah

How I Cut a Telemedicine MVP Down to Something a Clinic Could Actually Use

Kajol Shah — Wed, 08 Apr 2026 17:00:00 +0000

A lot of telemedicine products start the same way.
A founder says they want to build “a telemedicine app.”

Then version one starts sounding like this:

Patient App
Doctor Dashboard
Admin Panel
Messaging
Video
Billing
Device Data
EHR Integration

All at once.

That is usually the point where the MVP stops being an MVP.

The mistakes I see most often

The problem is not big plans.
The problem is trying to build a full platform before anyone knows what a clinic will use in week one.

A clinic does not adopt a product because it has the longest feature list. It adopts a product because one workflow becomes easier.

That's the way I look at it before any team starts building.

The question that changes the scope

Before talking about frameworks, timelines, or even budget, I ask one question:
What is the first care workflow this product needs to get right?

That question usually makes the scope much clearer. Because once you answer it, version one gets smaller fast.

Instead of trying to build everything, the team starts focusing on what belongs in the first release.

For many telemedicine products, that comes down to:

Patient intake
Appointment booking
Secure video through a vendor
Follow-up messaging
Provider access controls
Room for EHR or FHIR later

That is a very different build from trying to launch a complete digital care platform on day one.

What I would leave out of version one

This is the part founders usually resist. Not because the extra features are bad. Because they are too early.

Things I often push out of the first release:

Advanced reporting
Billing complexity
Custom video infrastructure
Broad admin layers
Wearables and device syncing
EHR integrations before the workflow is proven

Those things may matter later. They usually do not belong in the first version.

Why this matters technically too

This is not only a product problem. It is a delivery problem.

Every extra feature changes:

Timeline
QA effort
Extra situations
Access rules
Data handling
Maintenance cost

And in healthcare, once protected health information enters the picture, bad scoping creates security and compliance problems too. That is why a telemedicine MVP has to be shaped by workflow, not by a wish list.

Mobile first or web first?

This is one of the most common questions I hear. The answer depends on who uses the product most.

If patients are coming back for booking, reminders, and follow-up, mobile may lead. If providers spend most of the day at a desk, web may make more sense first.

A mixed setup is often the best starting point:

Mobile for patients
Web for providers

Trying to force both sides into one decision too early is another way teams make the first release heavier than it needs to be.

The real goal of version one

The goal is not to impress everyone with how much you built. The goal is to make one clinical workflow good enough that a real team will try it.

That is the point where feedback becomes useful. That is also the point where future decisions around security, integrations, and roadmap start getting clearer.

The checklist I’d use before development starts

Before any code gets written, I’d want clear answers to these:

What is the exact care workflow for version one?
Who uses the product most: patients, providers, or staff?
What can be handled by a third-party vendor instead of custom-built?
What data needs tighter access controls from day one?
What absolutely belongs in the first release?
What should wait until there is proof of use?

If those answers are not clear yet, the scope is probably too big.

Final thought

The fastest way to make a telemedicine MVP expensive is to turn it into a full platform too early.

The better move is to build the first workflow a clinic can actually use.

Everything else can follow after that.

If you're working through this right now, I wrote a fuller breakdown on HIPAA-aware telemedicine MVP planning here:
How to Build a HIPAA-Compliant Telemedicine MVP in the USA

The Hidden Costs of Third-Party APIs That Most Mobile Apps Ignore

Kajol Shah — Fri, 27 Mar 2026 14:00:00 +0000

I recently published a blog about something many founders and dev teams underestimate: third-party API costs.

At first, APIs feel like shortcuts — faster builds, fewer engineers, quicker launches. But over time, they quietly become one of the biggest cost drivers in your app.

Here’s what I’ve seen across real projects 👇

1. Pricing that scales against you
Most APIs charge per request. That’s fine… until usage grows. Suddenly, success = higher bills.

2. Hidden usage multipliers
One user action can trigger multiple API calls (analytics, auth, AI, payments). Costs compound fast.

3. Vendor lock-in
Switching providers later isn’t just technical — it’s expensive, risky, and time-consuming.

4. Unpredictable billing
Without proper monitoring, teams get surprised by invoices they didn’t see coming.

5. Feature creep = cost creep
Every small integration adds another line item to your monthly burn.

In my latest article, I break down how to:

Architect apps with cost in mind from day one
Avoid API billing surprises
Design systems that scale sustainably

🔗 Read it here.

If you're building with AI, payments, or any external APIs, this is something you cannot afford to ignore.

What’s the most unexpected API cost you’ve run into?

Architecting for Cost: How to Avoid API Billing Surprises

Kajol Shah — Tue, 24 Mar 2026 14:00:00 +0000

Developers love third-party APIs. They save us from reinventing the wheel. Need messaging? Use Twilio. Need payments? Plug in Stripe. Need maps? Google Maps API is ready. But while we focus on the ease of integration, we often overlook the long-term financial impact of how we write our code.

Poor architectural choices lead to hidden API integration costs for mobile apps. When we build for the USA market, where user expectations for real-time data are high, unoptimized API calls can result in massive end-of-month bills.

Where We Go Wrong

The most common mistake is treating a paid third-party API like a local database. Here are the architectural habits that drive up costs:

Aggressive Polling: If your app needs to know the status of a delivery, polling the API every 3 seconds is a fast way to run up a bill. Transitioning to webhooks ensures you only receive data (and incur costs) when a status changes.
Missing Cache Layers: If your app displays a daily exchange rate, there is no reason to call the financial API every time a user opens the view. Implementing a simple Redis cache or local storage mechanism to hold that data for 24 hours drastically reduces your request volume.
Unrestricted Front-End Requests: Allowing the client-side app to directly trigger paid APIs is dangerous. A simple bug in the useEffect hook in a React Native app can cause an infinite loop, draining your API credits in minutes. Always route paid API requests through your own backend, where you can enforce rate limiting.

The Real Cost of Maintenance

When we discuss mobile app ongoing maintenance expenses, we usually think about server hosting or developer retainers. However, third-party services often make up a larger percentage of the monthly overhead than the servers themselves.

Understanding third-party API pricing models is a core developer responsibility. It is not just a business problem; it is an engineering problem. Writing efficient code means writing cost-effective code.

Taking Control of Your Infrastructure

Before you push your next feature to production, review how often it calls the outside world. Set up strict billing alarms on your AWS, Google Cloud, and individual API dashboards.

If you are currently evaluating the architecture of a new build and want to see how these expenses map out alongside general development, check out our guide on the React Native App Development Cost in the USA. For a deeper look into auditing these specific service fees, read our full post: The Hidden Costs of Third-Party APIs in Mobile Apps.

Build smart, cache often, and protect your API keys.

Why Cost Per Screen Is a Weak Way to Estimate a Mobile App

Kajol Shah — Thu, 12 Mar 2026 15:00:00 +0000

A lot of early app estimates still start with a shortcut that sounds useful: cost per screen.

At first, it feels like a reasonable way to plan a budget.
Screens are visible.
They are easy to count.
They make the estimate feel organized.

But that shortcut falls apart pretty quickly once real work starts.

A profile screen, a payment screen, and a chat screen may all be counted as one screen in a basic estimate.

But they do not create the same amount of work.
A profile screen may need:

Form handling
Image upload
Validation
Settings updates

A payment screen may need:

Checkout flow
Failure states
Retries
Refunds
Billing records
Provider setup
Testing across multiple cases

A chat screen may need:

Message states
Unread logic
Moderation
Media handling
Push coordination
Backend persistence

So even if the screen count looks similar, the engineering work does not. That is one reason so many early app estimates feel fine in the beginning and then become difficult later.

The real cost usually moves because of:

Backend and admin scope
QA depth
Third-party integrations
Platform-specific work
Release work
Maintenance after launch

This is especially common when founders describe features in simple terms:

Basic admin panel
Simple payments
Standard notifications
Just a dashboard

Those phrases are fine for a first conversation, but they are not detailed enough for a useful estimate.

For developers, this creates a familiar problem. You may receive a feature list that looks small, but the hidden work is not small at all.

A more useful estimate looks at:

Hours by role
Work by phase
Platform scope
QA coverage
Backend complexity
Feature edge cases

That does not make the estimate perfect. But it does make it more honest.

It also helps explain why:

Two apps with similar UI can have very different budgets
One extra integration can change timeline more than a new static screen
Cross-platform still needs serious QA and release work
Post-launch costs need to be planned early

I recently turned this into a focused app cost calculator for startup teams. The point is not to guess the final quote exactly. The point is to make the main cost drivers easier to see before teams commit to a number too early.

If you want the full version, here it is.

React Native Quotes: 15 Questions To Ask Before You Pay Anyone

Kajol Shah — Thu, 05 Mar 2026 13:30:00 +0000

If you’re hiring someone to build a React Native app, you’ll get quotes that are very far apart.

A cheap quote is not always bad but a vague quote is bad.

This list is how I check if a quote is real, or just a guess.

15 Questions to Ask

1) What is included and what is not included?
Ask them to write it down in 5–10 bullet points.

2) Who owns the code repo on day one?
If they say we’ll share later, that’s a problem. You should have access from the start.

3) Will you use Expo or not? Why?
Plain answer you want: Expo is fine for most apps. If we need phone-specific work, we may not use Expo (or we will use a different setup).

4) Will you write any iPhone/Android-specific code?
If yes, ask: which feature needs it and how much time it adds.

5) What is the app’s first version (v1)?
Ask them to list the v1 screens/features. This stops extra work surprises later.

6) How many screens are you assuming?
Even a rough screen count is useful. Quotes change a lot when screens double.

7) What backend work is included?
Ask: Do you build the server, database, and APIs or is that extra?

8) Is an admin panel included?
Many quotes skip this. Ask what the admin can do (users, content, orders, refunds, etc.).

9) Which third-party services are included?
Examples: login, payments, SMS, email, maps, analytics, crash reports, storage. Ask them to list each service and who pays for it.

10) What is included for testing?
Ask:

How many devices they test on
iOS + Android versions
Who fixes bugs found after release

11) Who will handle App Store / Play Store release?
Ask: Do you set up accounts, certificates, signing, store listing, screenshots, and the first release?

12) What happens if Apple/Google rejects the app?
Rejections happen. Ask if the quote includes at least one round of fixes.

13) What is the timeline, and what are the checkpoints?
Ask for 3–5 checkpoints, like:

Clickable screens
Working login
Working main flows
Testing
Store release

14) How do changes work?
Ask:

What counts as a change
How changes are priced
How you approve changes

15) What do you need from me to start?
A good team will ask for things like:

A short feature list
Sample apps you like
Brand/logo
Admin rules
Payment rules
Content you want in the app If they ask for nothing, they may be guessing.

A Simple Rule

If they can’t answer these questions in writing, don’t pay yet.

If you want, use my copy/paste scope template.
I also keep a one-page checklist and a simple scope template here (with a printable PDF).

If you post your app idea (main screens + any services like payments/SMS/maps), I’ll tell you which parts are usually missing from quotes.

The 1-Page React Native Scope Template That Gets Real Quotes

Kajol Shah — Mon, 02 Mar 2026 13:30:00 +0000

Most app quotes are confusing because the input is unclear. If you send a vague idea, you get a vague price. Here’s a one-page template you can copy, fill in, and send to any team so you get quotes you can compare.

Template (copy/paste block)
Paste this into email / Notion / Google Doc:

Platforms: iOS / Android / both
User types: (example: customer + admin)
Login: email / phone OTP / Google / Apple
Main screens: (list screens, even rough)
Hard parts (tick what applies):
- Payments (Stripe / in-app / other)
- Maps / location
- Chat
- Video / audio
- File upload
- Bluetooth / device connection
- Offline use
- Push notifications
Data: what does the app store and show?
Backend: do you need one? Yes/No/Unsure
Admin panel: yes/no (what should it do?)
Third-party services: (Stripe, Twilio, Firebase, etc.)
Design: provided by me / need design help
Timeline: (date you want v1)
Must-have vs nice-to-have: (two short lists)
Deliverables I expect: source code access, builds, store release help, basic docs
After launch: do you want maintenance? Yes/No

How to use it?
Send this to 3–5 teams. Ask them to reply with:

What they assume you mean
What is not included
Timeline + milestones
What can change the price

I also put a printable one-page checklist and tentitive cost ranges here!

App Maintenance Cost In The USA (2026): Monthly Retainers And Surprise Line Items

Kajol Shah — Thu, 19 Feb 2026 17:35:00 +0000

Launch is not the finish line. In the US market, launch is when recurring costs start.

Here are the budget bands we see founders using for 2026 planning:

Light MVP: $500 to $2,000 USD per month
Growing app with regular releases: $2,000 to $7,000 USD per month
Complex app with revenue and integrations: $7,000 to $25,000 USD per month

Why the Cost Jumps After Launch:

Because real users do things your test team didn’t.
They update their phones.
They use bad networks.
They hit payment edge cases.
They turn notifications on and then complain when it gets noisy.

A Simple Way to Think About Retainers:

Tier 1 (Essential): crash fixes, small bugs, store submissions
Tier 2 (Growth): OS updates, analytics cleanup, push tuning, payment upkeep
Tier 3 (High responsibility): faster response, deeper QA, security cadence, performance work

We also reviewed 30 proposals and the most missed items were not extra features. They were maintenance basics like:

OS update plan
device testing matrix
dependency update cadence
store resubmission ownership
push rules (quiet hours, caps, time zones)

Full reference page with tables, checklists, and sources.

AI features shouldn’t go live without a Reset button

Kajol Shah — Thu, 12 Feb 2026 15:00:00 +0000

A bizzare thing happens when an app starts feeling smart:

It stops asking questions.

It decides.

And once it decides, you’re stuck living with that decision longer than you should.

I think any feature that adapts to users (recommendations, reminders, automation, smart defaults) should come with a Reset button.

Not hidden in settings.
Not clear data (nobody wants to do that).
A real, understandable reset.

Because people change and apps usually don’t notice fast enough.

The moment this goes wrong (it’s extremely common)

You open an app you used during a very specific phase:
Hookup era
Breakup era
Exam era
New job era
I’m going to become a fitness person era

…and the app treats that phase like your permanent identity.

You didn’t do anything wrong.
You just… moved on.

But the app keeps talking to an older version of you.

That’s why users don’t say this AI is bad.

They say:

This app is annoying now.
It doesn’t get me.
Why is it still doing this?

What a Reset button fixes (in plain product terms)

1) It prevents overconfident personalization.

If your app is guessing wrong, a reset gives users a way out that doesn’t feel technical.

Arguable take:

If you don’t offer a reset, personalization will eventually become a retention problem.

2) It makes automation feel less scary.

When apps auto-do things (we scheduled this, we reordered this, we suggested this), users start feeling watched or managed.

Reset is a small way of saying:

“You’re still in control.”

3) It helps your app adapt to life changes.

New routines. New goals. New time zones. New preferences.
A reset is a clean way to mark: That was then.

Reset doesn’t have to mean erase everything

Here are a few versions that feel normal to users:

Reset recommendations (start fresh)
Reset routine (my schedule changed)
Reset reminders (too many / wrong times)
Reset the assistant (it’s giving me the wrong kind of help)
Reset personalization (show me a broader mix again)

Even better: a soft reset:

This isn’t me anymore
Show less like this
I’m in a different phase
Start over

Where should Reset live?
1) Always visible on the main screen (strong opinion)
2) Only visible after the user shows frustration (safer)
3) Only in settings (common, but useless)

My opinion: if the feature changes what users see or get, Reset should always be one tap away.

Because the whole point is:

Users shouldn’t have to work to correct the app.

Quick checklist: when a feature needs Reset

If the feature…

Learns from behavior over time
Triggers messages (notifications, nudges)
Changes content order / feed
Changes what the user sees by default
Makes predictions without asking

…it needs a Reset.

I wrote a deeper breakdown here (what to build first vs later)

Here is the full guide on which smart features belong at which stage of a mobile app (and what to delay until trust exists).

I want to hear the opposing view

What’s your take?

Do Reset buttons make products feel less confident?
Or do they make products feel more respectful?

And: what’s one app you wish had a reset because it learned you wrong?

Personalization isn’t broken. It’s overconfident

Kajol Shah — Wed, 11 Feb 2026 05:29:05 +0000

Personalization goes wrong when it treats a moment like a permanent identity.

You click one thing out of curiosity and the app decides: 'This is you now.'
But real life changes constantly.

Examples you’ve probably lived:

One 'gym' search → fitness feed forever
One breakup song → weeks of 'healing' content
One expensive product click → 'high spender' assumptions
one travel plan → now your feed is only travel

The problem isn’t personalization. It’s premature certainty.

Here’s a simple fix model:

Soft personalization first (reorder content, don’t replace it)
Confirm big shifts ('Still into this?')

Let users correct it (mute topic, reset, show less)

Longer breakdown + timings

Debate: When should personalization start?
A) After 1–2 actions
B) After patterns (5–10 actions)
C) Only after explicit preferences
Pick A/B/C + share a good/bad example.

Most apps add smart features too early

Kajol Shah — Sat, 07 Feb 2026 16:00:00 +0000

A lot of founders think: 'If it feels smart, users will stay.'
But I’ve seen the opposite happen.

When advanced features show up before workflows are stable, users don’t feel impressed, they feel confused. The app becomes unpredictable. The learning curve grows. And churn rises quietly.

Common early mistakes:

Over-automating before users understand the basics
Predicting behavior from too little data
'Personalization' that locks in after one action
Features that change the UI without telling the user why

A simple rule I like:
Earn trust in layers.
Start with features that reduce effort without surprising the user. Then add prediction/automation only after behavior patterns are stable.

Full breakdown (what to build early vs later).

Debate: What’s worse for a new app?
A) No smart features early
B) Too many smart features early
Pick A/B and explain why.

In the USA, 'Smart' is the minimum now

Kajol Shah — Fri, 06 Feb 2026 16:00:00 +0000

US users don’t compare your app to 'apps like yours.' They compare it to the best experiences they already use daily: Netflix, Google Maps, Amazon, Apple Pay.

That changes what 'good' means. Smooth screens and fast load times aren’t impressive anymore. They’re assumed. What decides retention is whether the app feels helpful, personal, and less manual.

Here’s what 'less manual' looks like in real life:

It remembers preferences without asking again
It reduces repeated steps (fewer taps, fewer forms)
It adapts when routines change (work, travel, health, schedule)

And here’s the uncomfortable part: users rarely say 'this app lacks AI.' They just feel:

'Why do I have to repeat this every time?'
'Why is this so generic?'
'Why does it keep pushing the wrong thing?'

So the question isn’t 'should we add smart features?'
It’s: which ones matter now, and when should they show up?

Long version with examples + timing

Debate: In the US market, is 'smart' now required?
A) Yes, table stakes
B) No, great UX alone still wins
Comment A/B + your app category.

AI-Powered Website Features in 2026: 5 Things You Can Implement Today Without Frustrating Users

Kajol Shah — Wed, 04 Feb 2026 05:30:00 +0000

AI features are everywhere in modern websites: recommendations, personalized dashboards, search suggestions, and notifications. But let’s be honest: most AI implementations frustrate users more than they help.

The problem isn’t AI itself. It’s using it out of context. Users don’t want an algorithm telling them who they are or what they need. They want helpful nudges, smart suggestions, and relevant content.

Here’s how you can add AI features to your website today without pushing users away. I’ve included some mini implementation tips and code snippets to get you started.

1. Smart but subtle product recommendations
What goes wrong: Recommending products aggressively, showing the same items over and over.

Solution: Use AI to recommend based on recent actions rather than every click.

Mini tip: Track a user’s last 3–5 actions and adjust recommendations dynamically.

//Example using simple JavaScript logic with user history
const userHistory = ['running shoes', 'water bottle', 'headphones'];

function recommendProducts(history, allProducts) {
  return allProducts.filter(product =>
    history.some(item => product.tags.includes(item))
  ).slice(0, 3);
}

const recommendations = recommendProducts(userHistory, allProducts);
console.log('Recommended products:', recommendations);

Keep recommendations small and rotate them often. Too many suggestions create noise.

2. Context-aware notifications
What goes wrong: Reminders and pop-ups trigger too often or at the wrong time.

Solution: Trigger notifications only when they are actually useful.

Mini tip: Check for user inactivity or relevant events before notifying.

# Example: Python pseudo-code for notification logic
def should_notify(user):
    if user.last_action > 2*60*60:  # 2 hours
        if not user.dismissed_notifications:
            return True
    return False

Think like a user: “Would I care if this popped up now?” If not, don’t show it.

3. Dynamic search suggestions
What goes wrong: Autocomplete can overwhelm or suggest irrelevant results.

Solution: Make suggestions adaptive: prioritize recent searches, popular items, or exact matches.

// Example: Filter search suggestions based on query
const searchData = ['iPhone 14', 'iPhone case', 'iPhone charger', 'iPad Pro'];

function getSuggestions(query) {
  return searchData.filter(item => item.toLowerCase().includes(query.toLowerCase())).slice(0, 5);
}

console.log(getSuggestions('iPhone')); // Shows top 5 matches

Limit the results and show them quickly. Users scan, they don’t read.

4. Adaptive content blocks
What goes wrong: Showing content without considering what the user just did.

Solution: Adjust sections on the page dynamically based on behavior or interests.

// Example: Show blog recommendations based on visited pages
const userVisited = ['React', 'NodeJS'];
const allBlogs = [
  { title: 'React Core Web Vitals', tags: ['React'] },
  { title: 'NodeJS Observability', tags: ['NodeJS'] },
  { title: 'CSS Tricks', tags: ['CSS'] }
];

const recommendedBlogs = allBlogs.filter(blog =>
  blog.tags.some(tag => userVisited.includes(tag))
);

console.log('Recommended Blogs:', recommendedBlogs);

Avoid “static” personalization that assumes a user’s interest never changes.

5. Personalized dashboards or reports
What goes wrong: Forcing AI-generated dashboards on every user, even if they don’t care.

Solution: Make dashboards optional, with clear toggle controls.

<!-- Example: Simple toggle for a personalized dashboard -->
<label>
  <input type="checkbox" id="enableDashboard" /> Show personalized dashboard
</label>

<script>
  const toggle = document.getElementById('enableDashboard');
  toggle.addEventListener('change', () => {
    document.getElementById('dashboard').style.display =
      toggle.checked ? 'block' : 'none';
  });
</script>

Let users control personalization. It builds trust and avoids “pushy AI” feeling.

What’s your experience with AI-driven features on mobile/web apps? Have you found the perfect balance?