Parth TiwariStart a project
MenuClose

Start a project / A direct conversation

Have something real to build?

Tell me what you are trying to make. I will tell you what I can own, what needs proving first, and the smallest useful way to start.

Scope / Three kinds of work

Where I can be useful.

The shape can change. The boundary does not: the product has to remain understandable, testable, and honest about what the model cannot own.

  1. 01

    AI products people can use

    A working product in the browser, with the model, data, evaluation, and interface connected.

    Useful for

    • Retrieval over private material
    • Agents with bounded actions
    • Generation workflows with durable jobs

    Boundary

    • No unsupported benchmark or user claim
    • No pretending a prototype is production
  2. 02

    Business workflow automation

    Repeated work moves through a visible, recoverable workflow while people keep authority over consequential decisions.

    Useful for

    • Long-running workflow orchestration
    • Risk and fraud scoring
    • Scheduled infrastructure tasks

    Boundary

    • The model does not own lifecycle state
    • High-impact actions keep an explicit gate
  3. 03

    Interactive product storytelling

    A web experience that explains how the system works without hiding the useful page behind motion.

    Useful for

    • Data-led visual stories
    • Accessible interaction and reduced motion
    • Static fallbacks that keep the whole argument

    Boundary

    • Motion never owns navigation
    • A visual never invents project data

Process / Four clear moves

We make the uncertainty smaller.

This is the default path, not ceremony for its own sake. A project can begin smaller when the evidence says it should.

  1. 01

    Start with the actual problem.

    We get clear on who is stuck, what exists today, and what a useful change would look like.

    A problem worth solving

  2. 02

    Prove the risky part first.

    Before a large build, we test the assumption most likely to make the idea fail.

    Evidence, not momentum

  3. 03

    Build the smallest useful version.

    The interface, model, data, evaluation, and recovery path are connected around one real job.

    Something people can use

  4. 04

    Ship it, measure it, leave it clear.

    We document the decisions, keep the failure states visible, and decide the next step from what happened.

    A product you can continue

Fit / Better to know early

A good fit is more useful than a forced yes.

If I am not the right person, I will say so. If the idea needs proof before implementation, that is where I will suggest we start.

Likely a fit

There is something real underneath the idea.

  • There is a real workflow, user problem, or product idea behind the AI request.
  • The riskiest assumption can be tested with actual material or a bounded prototype.
  • A human keeps authority over decisions that affect money, access, health, or people.
  • You want the useful page and reliable system, not only the impressive demo.

Probably not a fit

The request needs the story to outrun the evidence.

  • The brief needs invented proof, hidden limitations, or a claim the evidence cannot support.
  • The model is expected to own consequential decisions without a review boundary.
  • The request is only “add AI” and there is no user problem to examine yet.
  • The project depends on pretending a prototype is already a production system.