Skip to content
Vincent InferidoFull-Stack AI-First Developer & UI/UX Designer
PlanningProcessBusiness

How I Plan a Project: From Discovery Call to Launch

A transparent walkthrough of how I take a project from a first conversation to a launched product, with what happens at each step, what you'll see, and what I'll need from you.

Vincent Inferido··4 min read
Share: X LinkedIn Facebook
How I Plan a Project: From Discovery Call to Launch
On this page
  1. The short version
  2. Step 1: A free discovery call (30 minutes)
  3. Step 2: A written scope and a fixed quote
  4. Step 3: Design before code
  5. Step 4: Build in small, visible pieces
  6. Step 5: Test, then launch
  7. Step 6: Handoff and support
  8. What I'll need from you
  9. The bottom line

Hiring someone to build software can feel like a leap of faith. You describe what you want, money changes hands, and you hope the result matches what you imagined.

It shouldn't work that way. Here is exactly how I run a project, step by step, so you know what to expect before we ever talk.

The short version

Step What happens What you get
1. Discovery call We talk about your business and the problem Honest advice on whether and what to build
2. Scope and quote I turn the conversation into a written plan A fixed-scope, fixed-price quote
3. Design We shape the product before any code is written Designs and a clickable prototype
4. Build I develop in small pieces Regular demos you can click through
5. Test and launch We check everything, then go live A working, launched product
6. Handoff and support You get everything you need to run it Access, documentation and a bug-fix period

Step 1: A free discovery call (30 minutes)

We start with a conversation, not a sales pitch. I'll ask about:

  • Your business, and the problem that made you reach out
  • Who will use the product, and what they need to get done
  • What success looks like, in plain terms
  • Timeline and budget, so I can suggest what's realistic

Sometimes the honest answer is "you don't need custom software. This existing tool will do." I'll tell you if that's the case. A clear "no" now is better than a project that shouldn't exist.

Helpful to bring: anything you've written down, examples of apps or sites you like, and your rough budget. (See What to Prepare Before Hiring a Developer.)

Step 2: A written scope and a fixed quote

After the call, I write up:

  • What we're building: the screens and features, in plain language
  • What's not included (yet), so there are no surprises
  • The timeline, broken into milestones
  • The price, fixed for the agreed scope, with payments tied to milestones

If the budget doesn't cover everything, we split it into phases: the must-haves first, and the rest when you're ready. Before we talk, you can get a feel for effort and timeline with the project estimator.

Step 3: Design before code

Changing a design takes minutes; changing finished code can take days. So we get the product right on screen first:

  1. User flows: how people move through the product, step by step
  2. Screen designs: what each page looks like, in your brand
  3. A clickable prototype: you can tap through it on your phone and feel the product before it exists

You review, give feedback, and we adjust until it's right. This step prevents most expensive changes later.

Step 4: Build in small, visible pieces

I don't disappear for weeks and come back with a surprise. The build happens in small increments:

  • Regular demos: you see working features as they're built, not just progress reports
  • Clear communication: one channel, quick replies (usually within 24 hours), no jargon
  • Early course-correction: if something doesn't feel right, we catch it early when it's cheap to fix

Under the hood I use modern, well-supported tools such as Next.js, TypeScript and databases like Supabase or Firebase, chosen for what fits your product. You don't need to know any of that to work with me. (If you're curious, read Supabase vs. Firebase.)

Step 5: Test, then launch

Before launch, we check:

  • Every user flow, on phones, tablets and desktops
  • Security and permissions: people can only see and do what they should
  • Real content and data, not just placeholder text
  • Performance: pages load fast

Then we launch together, with a plan for the day: going live, a final check, and me on hand in case anything needs attention.

Step 6: Handoff and support

When the project is done, you're not left alone with something you don't understand. You get:

  • Access to everything: code, hosting, domain and accounts. You own it.
  • A short guide for day-to-day tasks, like adding content or managing users
  • A bug-fix period after launch, so anything we missed gets fixed
  • Optional ongoing support for updates and new features, only if you want it

What I'll need from you

A smooth project is a team effort. From your side:

  • One decision-maker who can give feedback and approve designs
  • Timely feedback at each milestone (usually a few days' turnaround)
  • Content and access: text, images, logos, and logins for any services we connect

The bottom line

No mystery, no disappearing developer, no surprise invoices: a clear plan, designs you approve, regular demos, and a product you fully own.

Have a project in mind? Send me a message, or estimate your project first and send me the result. I'll reply within 24 hours.

Vincent Inferido
Vincent Inferido Full-Stack AI-First Developer & UI/UX Designer based in the Philippines. I design and build CRMs, booking systems, web apps and Web3 products for growing businesses.
Found this useful? Share it: X LinkedIn Facebook