Job ship-one-feature-with-running-preview · revised 9 October 2026
Add one small web-app feature you can try in a private preview
Try one agreed feature in a private, time-limited preview of your existing web app. Receive tests, screenshots and two revision rounds before you accept the result.
You might be seeing
- The existing app works, but one specific interaction or capability is not there
- A code diff alone would not let the buyer try that interaction and decide whether it meets the request
No passwords, keys, card details or admin invites needed to start.
What usually happened
One defined capability is missing from an existing web application. The buyer needs to use the changed app and compare it with written acceptance criteria; a pull request or screenshot alone does not provide a running result they can accept. A new product or an undefined improvement is a different scope.
Who it’s for: A founder or CTO with an existing web application and one well-described feature, who wants to try the result before deciding to merge or deploy it.
Usually starts when: A small capability is missing from an otherwise working application, and the buyer can describe the interaction and the result that would make it useful.
The result: The agreed feature works in an isolated, private preview that you can use with synthetic data. You receive its tests, screenshots and limitations, can request changes in two agreed revision rounds, and decide whether to accept it before payment. The pull request is the handover for your own merge and deploy process.
Check whether this job fits
Use these questions to bound the feature and its preview. Do not send code, credentials or customer data to answer them. A preview must be usable by you and unavailable to unauthorised visitors.
Checks you can run yourself
Describe the acceptance walkthrough
Write the steps a reviewer would take in a preview and the expected result at each step, using invented data. List what should remain unchanged in the existing app.
Look for: A finite walkthrough for one feature, a named reviewer and an existing safe preview route. Separate new requests from corrections to the agreed behaviour.
What you get
- A running private preview you can click through, with access instructions, test fixtures and its agreed expiry
- The written feature request and acceptance criteria, test results, screenshots of the final preview revision, limitations and revision feedback
- A pull request containing the implementation and tests, with run instructions and steps to reverse the change
- A record of your acceptance or requested changes; the customer-facing delivery is the preview and its evidence, not the pull request alone
Included
- One small, well-described feature in one existing web application, with its screens, interactions, expected results and exclusions agreed in writing
- Implementation and automated checks for the agreed behaviour, plus checks of the nearby existing paths named in scope
- An isolated preview using synthetic fixtures, protected by access control for the agreed reviewers and available only for the agreed review period
- Screenshots of the running feature at the agreed desktop and mobile sizes, test evidence and a pull request
- Two revision rounds: each is one consolidated list of changes against the agreed acceptance criteria, followed by a revised preview and evidence
Not included
- New products, full rewrites, whole-app redesigns or replacement of the application's architecture
- Features that need new third-party accounts or paid services
- Native mobile applications
- Changes touching payments or personal-data handling without a separate security review and separately agreed scope
- Unbounded requests such as 'make it better', unrelated bugs or features added during review
- Production deployment unless separately agreed; merging and deploying through the buyer's own gates remain the buyer's decisions
- Permanent hosting, unrestricted public previews or ongoing preview availability after the agreed expiry
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The named buyer-side reviewer can use the running preview to complete every agreed feature walkthrough with the expected results, and either accepts it or requests in-scope changes within the two agreed revision rounds.
Evidence: The written criteria, preview URL and source revision, completed walkthrough, consolidated feedback for each used round and the buyer's final written acceptance.
The feature's automated tests and the agreed nearby behaviour checks pass on the same revision shown in the preview, and the screenshots show that running revision at the agreed desktop and mobile sizes.
Evidence: Test commands and outputs tied to the preview revision, plus dated screenshots identifying that revision and viewport sizes.
An authorised reviewer can access the preview, an unauthorised session is denied, and the preview uses only isolated test resources and synthetic data with its expiry recorded.
Evidence: Redacted allowed and denied access checks, the preview resource and fixture manifest, an isolation review and the written access list and expiry plan.
The buyer receives the pull request, run instructions, limitations and reversal steps, while production remains unchanged by this job.
Evidence: Handover checklist and pull-request diff, with the preview-only execution record and explicit record that no production deployment was performed.
Sign-off. You use the preview and compare it with the agreed criteria. You can accept or submit one consolidated list of in-scope changes in each of two revision rounds. Payment follows your final written acceptance and passing checks, not merely delivery of a pull request. Your own approval to merge or deploy is separate; previews expire as agreed in writing.
If it fails. If the preview or agreed checks fail, you do not pay for this feature. We address in-scope corrections within the two revision rounds, or hand over the findings and stop. New features, sensitive-data work or extra rounds need a separate agreement; if the criteria remain unmet after the included rounds, there is no charge for an unaccepted result.
When it fits, and when we stop
It fits when
- The existing web app can already run from a named source revision in isolation with synthetic fixtures
- You can describe one feature's user interaction and observable result, and accept a written list of criteria before implementation
- An existing authorised preview route can provide access-controlled hosting without a new third-party account or paid service
- One named buyer-side reviewer can use the preview, consolidate feedback for two rounds and accept the result
- The feature can stay outside payment and personal-data handling changes within this scope
We stop and tell you if
- The request cannot be narrowed to one feature with written acceptance criteria, or requires a new application or rewrite
- The application cannot run in the agreed isolated preview without production data, credentials, a new third-party account or a paid service
- Review reveals that the change touches payments or personal-data handling and needs a separate security review before it can be scoped
- The preview cannot be protected for the agreed reviewers, or preview isolation would allow changes to production
- Feedback adds another feature or exceeds the two agreed revision rounds: we pause and agree separate scope before further work
What could go wrong
The preview uses a separate test environment and synthetic fixtures, so rejecting it leaves production unchanged. We can reset the preview to the starting revision or tear it down. Your team can close the pull request without merging, or later revert its named commits using the handover. Production deployment and any production rollback need your own release decision; they are not included here.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The preview exposes source, test data or an unfinished feature to unauthorised visitors. | Restrict access to the named reviewers, verify that an unauthorised session cannot open it, keep secrets out of screenshots and logs, and tear the preview down at its agreed expiry. A noindex flag or obscure URL is not the protection. |
| Preview actions send real email, write to production data or call a live external service. | Use synthetic fixtures and isolated resources. Disable or substitute outbound side effects and test that the preview has no production write route before buyer access. |
| A working preview differs from production, or feedback keeps expanding the feature. | Document preview assumptions and untested production differences. Agree criteria first and limit included feedback to two consolidated in-scope revision rounds; your own merge and deploy checks remain separate. |
An independent reviewer checks the feature against the written criteria in the actual preview, including desktop and mobile screenshots, test results and access restrictions. Your named buyer-side reviewer tries it and accepts or requests changes. Payments or personal-data handling require a separate security review before they can enter scope.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Ask your existing maintainer to implement the same written criteria and give you a protected test environment to try before merging. That avoids another code handoff and may be enough for one small feature.
- For a continuing queue of web requests, Unlimited Dev advertises its Web subscription at GBP 995 per month. Confirm stack fit, request size and how you review work; the page does not state private-preview terms. www.unlimiteddev.io
Questions
Do I get something I can use, or just a pull request?
You get a running preview and its test results and screenshots, so you can try the feature and accept or request changes. The pull request carries the implementation for your team to review, merge and deploy later.
Is the preview public or permanent?
No. It is isolated, private and access-controlled for the reviewers we agree with you. We agree its review period and expiry in writing, then remove access and tear it down. An unlisted link alone is not our privacy control.
How many changes can I request?
Two revision rounds are included. Each is one consolidated list of corrections against the agreed feature criteria. A new feature or more rounds needs a separate quote.
Will you release it to production after I accept?
Not in this job. Your own merge and deployment gates stay yours. Any production work needs a separate written agreement; accepting a preview does not authorise a live release.
Is £750 the fixed price for every feature?
No. It is the starting price. We read the request and agree the exact scope, preview route, acceptance criteria and fixed price in writing before implementation.
Start with an email
Send us
- A plain description of one feature: who uses it, the screen or operation, their actions and the expected result
- The existing app's platform and framework, whether an isolated preview already exists, and any public reference that shows the desired interaction
- The key acceptance criteria and who will try the preview; describe the request without attaching code or private tickets
- Do not send credentials, code, customer data, production exports or private-access invitations in the first enquiry
Later, once you agree
- The named source revision through a company-controlled repository or code-export route, run instructions and a branch route for the pull request
- Synthetic fixtures and test identities, with approved substitutes for outbound messages or external side effects
- The written feature scope, acceptance criteria, nearby checks and the two revision rounds
- The authorised preview route, reviewer access list, access-control method and review-period expiry agreed before implementation; no production keys
You keep the app, repository, customer data and production accounts. We work on an authorised copy through a company-controlled identity, never a personal login. The preview is isolated from production, private and access-controlled for named reviewers, with an expiry and teardown plan agreed in writing. An unlisted link or noindex flag is not access control. You keep your merge and deployment gates; we do not deploy to production unless separately agreed.
This writes an email to us with your request filled in; it reaches us when you send it. Or write to hello@syntheticindustry.ai with “ship-one-feature-with-running-preview” as the subject.