DEV Community: Rishita Sharma

Should AI be in your MVP v1, or added after the workflow works?

Rishita Sharma — Fri, 09 Oct 2026 04:42:12 +0000

Seeing a lot of teams lately rush an LLM into the first version of every product. Model costs keep dropping, so it feels cheap to add. But cheap to call is not the same as cheap to get right.

The rough rule I keep coming back to:

If the product is basically useless without the model (doc parsing, matching, summarising messy input), it belongs in v1. Then the real work is evals and failure handling, not the prompt.
If the core loop works with a person doing the step by hand for now, ship that first and add the model once you know what "correct" looks like.

The tradeoff cuts both ways. AI in v1 can make early feedback noisy, because you can't tell if users dislike the product or the model output. Adding it later can mean reworking the UX around it.

For regulated stuff (finance, health, compliance docs) I'd lean toward human in the loop first almost every time, just so there is a clean record of what the right answer was.

For whatever you're building right now, is the AI the actual hypothesis or more of a nice extra?

What I lock down before letting a coding agent run commands on my laptop

Rishita Sharma — Thu, 08 Oct 2026 04:54:36 +0000

GitHub made local sandboxing for Copilot generally available this week, in the CLI, the Copilot app and VS Code Agent Host sessions. Commands the agent starts run with restricted access to files, network and credentials, based on a policy you set.

I've been letting agents run commands locally for a while, mostly with no boundary at all, so this pushed me to write down what I actually care about.

Files

The agent should see the repo it's working on and nothing else. My home folder has SSH keys, cloud configs and old project stuff. None of it helps the agent fix a failing test.

Network

Most tasks need package installs and not much more. I'd rather allow the package registry and block the rest than find out later that some script phoned home.

Credentials

This is the one that worries me. If the agent can use my Git credentials, it can push. GitHub's sandbox lets you control access to Git and GitHub CLI credentials, and that's the setting I'd look at first.

What it costs

Friction. Some installs and tests will fail inside a sandbox and you'll spend time loosening the policy. I'd expect to tweak it a few times in the first week.

What I'd skip

Writing a perfect policy up front. Start strict, see what breaks, open only that.

One detail I liked in the announcement: model execution and tool isolation are treated separately, so the policy applies whichever model you pick.

Are you running coding agents inside any sandbox yet, or just trusting the diff review at the end?

Why I put one thin layer between my app and every LLM provider

Rishita Sharma — Wed, 07 Oct 2026 04:37:48 +0000

On my first AI feature I called one provider straight from the code that needed it. It worked, and for a while that was the right call.

Then I wanted a cheaper model for the boring tasks, like tagging and short summaries. That's when I noticed the provider was everywhere: keys in three places, retry logic copied around, and no clear idea what each feature actually cost.

Chalk's post this week cited an a16z survey where 81% of CIOs at Global 2000 companies now use three or more model families. I'm nowhere near that scale, but even with two providers the mess shows up fast.

What the layer does

It's small. Roughly:

One function per task type, like summarize or classify, not per provider.
The model for each task comes from config, so switching is a one line change.
A timeout and one fallback model, so a slow provider doesn't hang a user request.
A daily spend limit per key. I got this one after a retry loop ran all night once.
A log line per request with task, model, tokens and latency.

What it cost me

Another thing to maintain. Tool calling and structured output formats differ between providers, so the abstraction leaks. I ended up with small adapter code per provider anyway.

It also tempts you to over build. I'd skip it until a second provider is actually on the table.

What I'd do again

The per task log. Seeing that one feature used most of the tokens changed what I worked on next more than any routing trick did.

If you're running more than one model, did you build your own layer or use a gateway?

What I cut from my MVP to ship it in weeks, not months

Rishita Sharma — Tue, 06 Oct 2026 04:51:37 +0000

The first version of my last MVP had a feature list that would have taken months. I shipped something in a few weeks instead, mostly by deleting things I was sure we needed. Here is what went, and what I regretted.

Accounts and roles

I had planned an admin panel, team invites and three permission levels. The first users were a handful of people I knew by name. I gave them logins by hand and kept a spreadsheet of who could see what. Nobody noticed.

Settings pages

Every setting I had sketched was really me avoiding a decision. I picked sensible defaults and hardcoded them. When two people asked for the same change, that became the first real setting.

Payments

I didn't wire up a checkout. The first people who wanted to pay got an invoice by email. It felt a bit embarrassing, but it told me who was serious faster than a pricing page would have.

Notifications

Email and in-app notifications were on the list. I sent updates myself, by hand, for the first few weeks. That also meant I was talking to every user, which turned out to be the most useful part.

What I kept

The one workflow people came for, done properly. Error logging. A way for users to tell me something was broken. Backups. I didn't want to cut anything that would lose someone's data or leave me blind when it broke.

What I regretted cutting

Basic analytics. I skipped it to save a day, and then spent weeks guessing which screens people actually used. I'd add it from day one next time, even something rough.

Search too, a little. I thought nobody would have enough data to need it. A couple of heavy users did within the first month.

The rule I ended up with

If I could do it by hand for the first group of users, it stayed out of the code. If skipping it could lose data or hide errors, it stayed in.

What did you cut from your first version that you later wished you'd kept?

The India Company Compliance Checklist I Wish I Had in Week One

Rishita Sharma — Mon, 05 Oct 2026 09:17:15 +0000

When I set up my first company in India, I assumed incorporation was the hard part. It was not. The real work started after the certificate arrived, when a steady list of compliance tasks began landing on my desk.

Here is the short checklist I wish I had kept from week one.

Right after incorporation

Open the current account early. Banks ask for several documents and the process can take longer than you expect.
Get your PAN and TAN sorted and saved in one shared folder that your cofounder and accountant can both reach.
Check whether GST registration applies to you now or later. Registering too early can mean filing returns with nothing to report, which is still work.

The recurring stuff

Board meetings and minutes. Even a tiny private limited company needs them on a regular schedule. I keep a simple template and fill it in the same day.
Annual ROC filings. These have fixed windows and late fees add up quietly.
TDS on payments to contractors and vendors. This one surprised me most, because it shows up the moment you pay your first freelancer.

What actually helped

The single most useful habit was a shared compliance calendar. Every due date goes in with a reminder two weeks ahead. Nothing clever, but it removed the panic of discovering a deadline the night before.

The second habit was choosing an accountant who explains things instead of just filing them. I did not need to become an expert, but I needed to understand why each filing existed so I could plan cash around it.

The third was keeping founder agreements and share records clean from day one. Fixing them later, especially before raising money, is slow and stressful.

The takeaway

Compliance in India is not difficult once it is routine. It becomes painful only when it is invisible until the last minute. Treat it like any other recurring product task with an owner and a due date.

What is the one compliance task that caught you off guard after you registered your company?

A practical growth loop for early products

Rishita Sharma — Fri, 02 Oct 2026 07:15:15 +0000

Early growth gets clearer when treated as a learning loop, not a channel checklist.

Start with one painful use case and a narrow audience. Then run small experiments that produce real conversations: a useful guide, a focused landing page, a lightweight tool, or a hands-on onboarding session.

Track the signals that show learning: repeated customer language, activation, retention, and the objections that keep coming up. The best experiment is the one that improves the next message or product decision.

Once one path shows repeatability, document it before adding more channels. Sustainable growth usually comes from making one useful promise easier to discover, understand, and try.

How Small Feedback Loops Make Product Decisions Lighter

Rishita Sharma — Thu, 01 Oct 2026 16:02:00 +0000

Product work gets heavy when every decision depends on a large research project. A smaller feedback loop can keep the team moving without hiding uncertainty.

A useful weekly rhythm is simple:

Choose one uncertainty that matters.
Run the smallest test that can teach you something.
Compare what you expected with what you observed.
Record the decision and the next step.

The important part is the decision log. Keep it short, share it where the team already works, and revisit it during planning. The goal is not perfect prediction. It is making learning visible soon enough to change what happens next.

What is the smallest feedback loop that has improved a product decision for your team?

Hiring Engineers vs Outsourcing: A Practical Decision Framework

Rishita Sharma — Thu, 01 Oct 2026 15:15:49 +0000

For a young company, the question is rarely “Should we hire or outsource?” in the abstract. The better question is: which capability must become a permanent advantage, and which piece of work can be bought safely for a defined period?

That framing prevents two expensive mistakes: hiring a large team before the problem is understood, and outsourcing the exact knowledge the company will need to own later.

Start with the work, not the job title

Break the roadmap into three buckets:

Core learning: work that helps you understand users, workflows, or product-market fit.
Core advantage: technology or domain knowledge that will differentiate the business.
Commodity delivery: well-understood work with clear inputs and outputs.

Core learning usually needs close founder involvement. Core advantage should gradually be owned by an internal team. Commodity delivery can be outsourced when the quality bar and acceptance criteria are clear.

This is more useful than saying “we need three developers.” You may actually need one product-minded engineer to run experiments, a specialist for a short integration, and a reliable partner for a bounded piece of delivery.

When hiring is the better choice

Hire when the work is continuous, ambiguous, and tightly connected to customer feedback. An internal engineer is a better fit when they will:

make product trade-offs every week;
work directly with users or operations;
maintain systems after launch;
build context that compounds over time; or
protect sensitive domain knowledge.

A good first hire is not necessarily the most senior person available. It is someone who can make sensible decisions with incomplete information, communicate trade-offs, and leave the codebase easier to understand than they found it.

Before hiring, define the first 90-day outcome. “Build the platform” is not an outcome. “Enable ten target customers to complete the core workflow and give us reliable usage data” is much more useful.

When outsourcing is the better choice

Outsource when the work is bounded, specialized, or temporarily exceeds your capacity. Examples include a one-time design system, a security review, a migration, a narrowly scoped mobile build, or a well-specified integration.

Outsourcing works best when you can provide:

a written scope and explicit non-goals;
examples of acceptable quality;
one decision-maker on your side;
access to a staging environment and test data;
milestones tied to working software; and
a handover plan that includes documentation and credentials ownership.

Avoid outsourcing a vague idea and hoping a vendor will discover the product for you. You may receive polished output that solves the wrong problem.

The hybrid path is often healthiest

Many startups benefit from a small internal product owner plus a carefully scoped external team. The internal person owns priorities, user feedback, architecture decisions, and acceptance. The external team accelerates delivery without becoming the only source of context.

Set a weekly demo with real scenarios, not slide-deck status updates. Keep the repository, cloud account, domain, analytics, and deployment pipeline under company-controlled accounts from day one. If a partner disappears tomorrow, you should lose velocity—not ownership of the product.

A simple scoring exercise

Score each workstream from 1 to 5 on four dimensions:

how often requirements will change;
how important the knowledge is to your long-term advantage;
how difficult quality is to verify externally; and
how sensitive the data or workflow is.

High scores point toward hiring or building internal capability. Low scores point toward a well-scoped vendor engagement. If the scores are mixed, start with a short paid discovery sprint, document what you learn, and decide again with better information.

The goal is not to minimize headcount or vendor spend. It is to keep learning close to the business while buying speed where the risk is manageable. Build the capabilities that compound; outsource the work that has a clear finish line.

MVP vs PoC: What Should You Build First?

Rishita Sharma — Thu, 01 Oct 2026 15:15:12 +0000

A proof of concept and a minimum viable product answer different questions. Treating them as the same thing is one of the easiest ways to spend a month solving the wrong problem.

A PoC asks: can this work?

An MVP asks: will a specific group of people use this enough to create a sustainable business?

That distinction matters for both founders and engineering teams.

When a PoC is the right first step

Use a PoC when the biggest risk is technical or operational uncertainty:

Can an unfamiliar API handle the required volume?
Is the model accurate enough on real, messy data?
Can two systems exchange data reliably?
Is the latency acceptable for the workflow?
Can the team meet a security or compliance constraint?

A PoC should be deliberately narrow and disposable. Use representative data, measure the risky part, and set a time limit. If the risk is not retired after that time, you have learned something valuable: the idea needs a different approach or should be paused.

Do not turn a PoC into a product by accident. Production authentication, billing, analytics, polished UI, and support processes are usually distractions at this stage.

When an MVP is the right first step

Build an MVP when you already understand the main feasibility risks and the uncertainty is about behavior. The goal is to create the smallest complete loop for one user type:

A real user has a recognizable problem.
They can complete one useful workflow.
You can observe what happened and ask why.
They have a reason to return, pay, or refer someone.

An MVP can be technically simple without being careless. A spreadsheet behind a small interface, a manual operations step, or a limited integration may be perfectly reasonable if it helps you learn. The important part is that the user receives a real outcome, not a demo that only looks convincing.

A practical decision test

Write down the top three assumptions behind the idea. For each one, label it as either:

Feasibility: can we make it work?
Desirability: does the user actually want it?
Viability: can this become a repeatable business?

If feasibility is the largest unknown, run a PoC. If users have already confirmed the problem and feasibility is understood, build the smallest MVP. If both are uncertain, time-box a technical spike and pair it with five to ten conversations with the target users. Neither artifact replaces customer evidence.

What to measure

For a PoC, measure the risky technical outcome: accuracy, latency, failure rate, cost per transaction, or integration reliability. A successful PoC is evidence, not a feature list.

For an MVP, measure behavior: activation, completion of the core task, repeat usage, time to value, and the quality of user feedback. Revenue is useful, but early on a strong signal can also be a user who changes their workflow or introduces a colleague without being asked.

The best teams keep both artifacts small. A PoC retires technical uncertainty; an MVP creates a learning loop with users. Choose the one that addresses your biggest unknown, and define the evidence you need before writing the first ticket.