The short version
You’ll have a product that handles real users without the demo-only cracks: sign-in works, billing behaves, changes are scoped, and you can ship updates without fear.
Most people come to me when a prototype has paying users, but the next version has to be stable enough for sales and support, not just a demo. You’ll end up with a build you can run, change, and hand to another developer without guesswork. Next I’ll pin down scope, a technical plan, and a price you can sign off on.
I start by writing down what “done” means, then I build in a way that keeps the risky parts visible early. You’ll see the flows before I code them, you’ll see a staging version before it goes live, and I’ll document the decisions so fixes don’t turn into archaeology.
About me
I’m Eoin Kelleher, a product and software builder. I got into this work by being the person who had to carry a product from “it works on my laptop” to something customers could pay for and rely on, with onboarding, permissions, and support in the same room as the code.
People hire me when they want one person to own the details end to end. I keep scope in writing, I surface trade-offs before they become rework, and I leave a build that another developer can pick up. I won’t ship a payment system without tests around the money paths, and I won’t treat documentation as an afterthought.
How the order runs
Once you sign, I book the slot, set up a shared workspace for decisions, and start with a short planning pass. From there you’ll see progress in checkpoints, with approvals where a change would affect time, cost, or risk.
1. Plan the rebuild On order I’ll take your current prototype, notes, and any existing code and turn them into an agreed scope and a technical plan. You’ll approve what’s in and what’s out, plus the few decisions that change the shape of the build, like roles, data ownership, and environments. 2. Flow and data check Within a week I’ll share a clickable set of key flows and a plain-language data model so you can sanity-check how the portal behaves before I commit to code. You’ll review the screens and edge cases that usually break later, like invite flows, password resets, and role changes. 3. Build on staging Weeks 2 to 4 I’ll build the MVP on a staging environment that you can click through at any time. You’ll get regular checkpoints with what changed and what’s next, and I’ll call out any scope changes the moment they appear, with options and their time impact. 4. Launch and handover On delivery I’ll ship to production, run a release checklist, and stay close for launch-day fixes. You’ll get access, docs, and a handover session that covers how to run the product, how to add features safely, and what I’d tackle next if you keep iterating.
Discovery and requirements workshop
A structured session and follow-up notes that turn your spreadsheet and prototype into a written scope, a priority list, and clear acceptance checks for each key feature.
CLICKABLE FLOW WALKTHROUGH
A clickable set of core screens for the portal and admin areas, used to confirm navigation, permissions, and edge cases before build work starts.
DATA MODEL AND API PLAN
A plain-language data model and an API outline that covers key entities, ownership, and integrations, so future changes have a map to follow.
MVP web app build on staging
A working staging release of the web app MVP with the agreed roles, flows, and core features, ready for review and acceptance before production launch.
STRIPE SUBSCRIPTIONS AND BILLING SETUP
Stripe wiring for subscriptions, including plans, trials, cancellations, and refunds, plus webhook handling so your app stays in sync with billing events.
AUTHENTICATION AND ACCESS CONTROL
Login and access control using OAuth or SSO where needed, with role-based permissions and the account flows that keep support load down.
What it costs
This pricing covers the product build and rebuild described above, from planning through launch and handover.
Priced items
Getting started
If you want me to start product build and rebuild, the next step is to lock the slot and get the first planning call on the calendar.
1. Sign the proposal so I can book the work. 2. Pay the 40% booking invoice within 14 days of its date. 3. Send access to the current build, docs, and accounts so planning can start.
WHAT ARE YOU BUILDING THIS IN, AND CAN SOMEONE ELSE MAINTAIN IT?
I’ll propose a stack during the planning step and write down the reasons, including hiring and maintenance. I build with readable structure, tests around the risky paths, and setup notes, so another developer can run it and ship changes without guessing.
IF WE ADD PAYMENTS, HOW DO WE HANDLE TRIALS, CANCELLATIONS, AND REFUNDS?
I set this up so Stripe is the source of truth for billing state, and the app reacts to Stripe events through webhooks. You’ll get agreed rules for trial start and end, what happens on cancellation, and how refunds affect access.
Signature
Fee summary
How do we keep customer data safe and stay GDPR-sane?
I keep data access tight with roles and least-privilege defaults, log sensitive events, and avoid putting personal data in places it doesn’t belong. You’ll also get a simple map of what data you store, where it lives, and how to delete it.
WHAT DO YOU NEED FROM ME EACH WEEK SO THIS DOESN’T STALL?
I need one decision window each week for scope questions and approvals, plus access to the current prototype, any analytics you trust, and the accounts that gate progress like domains, Stripe, and OAuth providers. If something blocks me, I’ll name it the same day.
Payment
40% is due to book the work when you sign. The remaining 60% is due when the order is delivered. Invoices are payable within 14 days of the invoice date.
Start and schedule. I start the planning step once the booking payment is in and I have access to the current prototype and the accounts that gate progress. If access slips, the timeline moves with it.
Your weekly input. Each week I need one decision window for scope questions and approvals. If I am waiting on a decision or access, I will name the blocker the same day and park that thread until it clears.
Approvals and rework. I build from agreed notes, the clickable flow, and the data model. If you change a decision after approval, I will price and schedule that change before I implement it.
Staging and production
You will review builds on staging before launch. I will not push to production until you confirm the staging build is approved for release and the production accounts and domains are ready.
Billing rules and refunds. Stripe is the source of truth for billing state, and the app reacts to Stripe events through webhooks. I will write down the agreed rules for trials, cancellations, and refunds, then implement to that.
Security and GDPR basics. I will set roles and least privilege defaults, log sensitive events, and avoid putting personal data where it does not belong. You will also get a simple map of stored data and deletion steps.
Warranty and limits. If something I shipped does not match the agreed plan, I will fix it. I cannot cover outages or changes in third party services like Stripe, OAuth providers, hosting, or app stores.
