Project app-stabilise-critical-user-flows · revised 11 October 2026
Project
Stabilise the critical flows of one web app, each with a check that stays
Pick up to five flows that must work (sign-in, signup, a key form, a webhook, the main screen). Each is fixed where broken and gets an automated check; a provider sign-in adds a recorded manual test.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the flow list, the price and the terms in writing.
The result you are buying
The app's most important journeys have each been repaired, if at all, in isolation, with no shared test that proves they work together. Fixes break neighbours, and the same faults return. A dependable app needs the flows agreed, repaired where broken and each covered by a check that fails when it breaks again.
Who it’s for: A founder or product owner whose app was built quickly by a small team or an agency and has a handful of flows that sometimes break in production, with no automated way to tell.
Usually starts when: Before a launch, a funding round or a customer demo, or after a run of complaints about sign-in, forms or missing data, when you want the whole set of critical flows made dependable rather than fixed one by one.
The result: You buy the finished set of flows, not the individual tickets. Each agreed flow passes an automated end-to-end check against a test environment and is accepted by you, or is removed from the list in writing. For a sign-in through an outside provider, the automated check goes as far as the hand-off and a stubbed or test-mode return, and the real round trip is a recorded manual test with a provider test account.
How the work fits together
The project is complete when every agreed flow passes its automated check and you have accepted it, or it has been removed from the list in writing. You accept the finished set, not each internal step.
Fix users being logged out straight after a successful login Job Optional
After login, a test user stays signed in across page loads in the agreed environments, and across a browser restart where a lasting session is agreed. The cookie is set, sent back and kept.
One, if sign-in does not stay signed in
Used where the login journey is one of the flows and it drops the session.
Fix one social sign-in that fails with a redirect or callback error Job Optional
One named sign-in provider completes login in the environments we agree: the provider accepts the callback and your app starts a signed-in session. You review and release the change.
One, if a social sign-in fails at the callback
Used where a provider sign-in is one of the flows; its recorded manual round trip with a provider test account is the check against the real provider.
Fix one webhook endpoint that rejects genuine events as unsigned Job Optional
One named provider's test events pass signature verification at your endpoint, and forged or altered events are rejected. You review and release the change.
One per provider that sends events
Used where an incoming webhook is one of the flows.
Stop junk submissions on one web form without blocking real people Job Optional
One named form rejects a fixed set of junk submissions on the server and still accepts a fixed set of genuine ones, including unusual names and addresses. You review and release the change.
One, if a form is one of the flows
Used where a public form is one of the flows.
Fix a screen that goes blank or spins forever when data fails or is empty Job Optional
One named screen shows a clear loading, empty, error-with-retry or partial-data state for each agreed failure instead of a blank page or endless spinner, proven with simulated responses.
One per screen that goes blank or stuck
Used where a main screen fails on missing or failing data.
Fix a Supabase table that returns nothing to signed-in users, safely Job Optional
On one Supabase table a signed-in test user sees and changes only their own rows, while a second user and a signed-out visitor see none of them, shown by a repeatable test.
One per table, if data access rules are the cause
Used where the app is built on Supabase and a table returns nothing.
Fix one reproducible bug with a failing-then-passing regression test Job Optional
One reproducible bug in one codebase: a regression test fails before the fix and passes after it. You get the repair pull request and both test results to review.
One for each other reproducible bug on the list
Used for any bug that none of the specific jobs above covers.
How an engagement works
The price covers the agreed flows only. Flows you add later are quoted separately, and flows that turn out to be bigger jobs are re-scoped with you and priced in writing before work on them.
How it starts
You send the list of flows, how each fails and the steps to reproduce it, and tell us which matter most.
From your written descriptions alone, without access to your code, a copy or an environment, we propose which flows are in the project and a fixed price.
You agree the list, price and terms in writing. Nothing starts, and we have no access to anything of yours, before then.
After you agree, we reproduce each failure on a copy. A flow that is bigger than quoted or cannot be reproduced is re-scoped with you in writing, and anything it adds is priced in writing before work on it.
We repair and check each flow, sending a pull request and its evidence for you to accept.
We run all the automated checks together, send the final summary and hand over anything left open.
Who decides what
You decide which flows are on the list and accept each one. Your team merges and deploys on its own gates.
Handover
Each accepted flow arrives as a pull request with its checks and run instructions. Anything left unfinished is handed back with notes.
Sharing your product safely. Send descriptions of the flows and the steps to reproduce each, never code, customer data or credentials. After you agree the project in writing, invite us to a repository or fork you control and set up a test environment with test accounts.
What is included, and what is not
- A pull request for each repaired flow, with its tests
- The set of automated checks and instructions for running them
- For each outside-provider sign-in, a redacted recording or screenshots of the manual round trip
- A final summary: flows accepted, flows removed, and anything that turned out to need a bigger job
Included
- Up to five flows on one web app, agreed in writing from your written description of each flow, how it fails and the steps to reproduce it
- After you agree, a reproduction of each failure on a copy; a flow that turns out to be bigger than quoted, or cannot be reproduced, is re-scoped with you in writing, and anything it adds is priced in writing before work on it
- Each broken flow repaired using the same jobs you could buy alone, where they fit (sign-in callback, login session, incoming webhook, form rules, screen states, data access rules)
- An automated end-to-end check for every agreed flow, using a test account and synthetic data
- For a flow that signs in through an outside provider (for example Google or GitHub), the automated check goes as far as the address the app sends the user to and a stubbed or test-mode provider return that the app can accept in the test environment; it never drives the provider's own sign-in page. Any change to the app's deployed code for that return is agreed with you first. The real round trip is a recorded manual test with a provider test account, as in the callback job
- A single run of all the automated checks together on a clean copy, with the results
- A written final summary showing each flow and how it ended
Not included
- Flows added after the price is agreed, unless you add them to the list in writing
- New features, redesigns or migrations to another framework
- Production access, deployments or live data, which stay with your team
- Security audits, penetration tests or compliance certification
- Fixing faults inside third-party services
- A guarantee that every flow on a draft list can be repaired: any that cannot are named and removed or re-scoped with you
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every agreed flow either passes its automated end-to-end check against the test environment and is accepted by you, or is removed from the list in writing. For a sign-in through an outside provider, the automated check covers the hand-off and a stubbed or test-mode return, and the real round trip passes as a recorded manual test with a provider test account.
Evidence: The final summary, with your acceptance or removal recorded for each flow, and a redacted recording or screenshots of each manual provider round trip.
Each automated check fails on the unrepaired revision for the agreed fault and passes on the repaired revision.
Evidence: The check output before and after, attached to each pull request.
All automated checks pass together in one run on a clean copy with every accepted change applied.
Evidence: A single passing run of the full set, with its log.
Sign-off. You accept each flow, or send it back with comments, and then you accept the finished set.
If it fails. A flow we cannot repair is named with the reason and what it would take, and is taken off the list with a matching change to the price. Nothing is billed as delivered that you have not accepted.
When it fits, and when we stop
It fits when
- You can describe each flow as a journey with an expected result
- The app can run in an isolated copy with test accounts and synthetic data that hold no customer information
- A person on your side can accept changes, merge and deploy
- A sign-in through an outside provider needs a test account at the provider and a non-production environment that can run it
- The optional repair jobs fit only where the app uses what they need (React or Next.js for blank screens, Supabase for data access rules); any other bug is quoted as a separate bug fix
We stop and tell you if
- Most flows cannot be exercised without production access or real customer data
- The list is really a rebuild, so we propose a different scope
- Nobody on your side can accept changes
What could go wrong
Every flow is a separate pull request that your team merges, so any one can be reverted on its own. If the project stops, accepted flows stay accepted and the rest is handed back with notes.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Flows are bigger than they looked, or a fault lies in a service outside your code. | We price from your written descriptions and reproduction steps, reproduce each flow on a copy after you agree, and name and re-scope in writing any that is bigger or external before work on it. |
| Repairing one flow breaks another. | Every flow has a check, all automated checks run together at the end, and an independent review looks for side effects before you see each change. |
| The list changes while we work. | The price covers the agreed list. Additions are written in and quoted, never absorbed silently. |
| A sign-in check that never reaches the real provider is read as proof that the real sign-in works. | For an outside-provider sign-in the automated check stops at the hand-off and a test-mode return, and the summary says so; the real round trip is a recorded manual test with a provider test account. |
Each change is reviewed separately from the work that produced it, and you accept every flow. No human supervisor is included unless your proposal names one. At launch the work is largely automated, and we say so.
Stays with a person
- You accept each flow
- You merge and deploy on your own gates
Access we would need
- Read access to a repository or fork you control; no production access
- A test environment with test accounts
Questions
Do I buy tickets or a result?
A result. You agree the list of flows and a price, and you accept the finished set. How we get through the flows is our job.
What if a flow cannot be repaired?
We name it with the reason, take it off the list and adjust the price to match. You are not billed for work that is not accepted.
How is this different from the monthly service?
A project ends when its flows are repaired and accepted. The monthly service then checks up to four named flows every week, plus up to four release checks a month, and fixes up to two failures a month. This project allows up to five flows and is a one-off.
Do you test the real Google or GitHub sign-in automatically?
No. The automated check goes as far as the address the app sends the user to and a stubbed or test-mode return. The real round trip with the provider is a recorded manual test with a provider test account, and we do not drive the provider's own sign-in page.
Send an enquiry
Send us
- A list of the flows, in order of importance, with a sentence on how each fails and the steps to reproduce it
- The framework and hosting service, and whether there are existing tests
- Who accepts changes and who deploys
- Do not send code, credentials, customer data or an access invitation in the first enquiry
Later, once you agree
- Only after you have agreed the flow list, price and terms in writing: source access through an agreed company-controlled route, with a branch or fork for pull requests
- A test environment with test accounts and synthetic data
- Run instructions, and a provider test account for each outside-provider sign-in
Your repository, accounts and data stay yours. Before you agree in writing we need no code, copy or environment. After that we work on branches or a fork you control through a company-controlled identity, never a personal login, and return pull requests. We use test accounts and synthetic data and never hold production keys.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “app-stabilise-critical-user-flows” as the subject.