Developer workflow
How developers get assigned, wait for payment, submit a ZIP or GitHub snapshot, verify the delivery, then send it to live review.
Published · Updated
You build off-platform while the project is in_progress. Velcio keeps the delivery as a ZIP (upload or GitHub snapshot).
Before paid work
Pick a username at sign-up. Buyers assign you by that name. They do not see your email.
Under Developer profile you can add a photo, GitHub and website. A photo is required before marketplace opt-in. You can appear on the marketplace without Stripe Connect, but Connect is required before paid work or proposals.
Getting the job
Open listings: browse Open projects and send a priced proposal (Proposals). If they accept, you are on that price. Wait for them to fund, then wait for payment to clear before you start.
Email invite: open the link, sign up or sign in with that email, accept the invite.
Directed hire: negotiate in Pricing (opening offer, quote or counters). Open-listing work is already priced when your proposal is accepted.
After they fund
Do not start until payment is taken and status is in_progress (usually 24 hours after fund). Decline while funded if you cannot take it.
While in_progress, declare the env var names your code reads (DATABASE_URL, OPENAI_API_KEY and so on). Save early so the buyer can set secrets before you submit. You never receive their secret values.
Build off-platform. Submit when ready.
Submit delivery
Upload a ZIP or import from GitHub.
- Build mode: Auto (buildpacks) or Dockerfile
- Process: Worker (no public URL) or Web (
*.velcio.app) - Web must listen on
PORT(Velcio sets8080) and implementGET /healthzreturning HTTP 2xx - Layout rules: Delivery format
Verify, then send to review
After Velcio builds and deploys, check the Web URL if you have one, read logs, redeploy or submit a fix while status stays submitted. Runtime cap matches buyer review (default 120 minutes per run). A failed deploy (missing secrets, for example) returns to in_progress. A good retry returns to submitted.
When you are happy, confirm delivery. That starts buyer review and the review deadline. It opens a fresh buyer review runtime window. For Web, Velcio requires public GET /healthz → HTTP 2xx on the preview URL before confirm succeeds.
When they accept
You assign ownership of the delivered source to the buyer. Do not reuse it for other clients unless they agree outside Velcio. You lose project access. The payout hold clock starts at accept or auto-accept (you get a timing email).
Proposals
You need developer mode, Connect finished and marketplace availability on.
Include price (£), pitch, answers to listing questions, optional estimated days and included change rounds (0–20). That number locks at fund.
You can update a pending proposal or withdraw and submit again. New proposals and re-submits after withdraw are capped at 5 per rolling 24 hours. Editing a pending proposal does not use another slot.
Listings show whether the buyer viewed your proposal. On accept you are assigned at that price. Wait for fund, then for payment to clear.
Directed hires still use Pricing for offers and counters. Put included change rounds on each price offer there too.
GitHub import
Instead of a ZIP:
- Settings → Developer profile → Connected GitHub
- Connect or reinstall the Velcio GitHub App
- On Delivery, choose Import from GitHub, pick repo and ref, confirm the commit, submit with runtime and env vars
One-time snapshot of that commit. Later pushes do not redeploy. The GitHub URL on your marketplace profile is only a public link. It does not connect the App.
Payouts
Connect Stripe Express under Developer profile before paid work, proposals or transfers. Hold timing: Developer payouts.
Use Discussion on the project to talk at any stage.
Packaging
- ZIP / GitHub: Delivery format
- Web HTTP (
PORT,/healthz): Web delivery format - Problems: Troubleshooting
Revisions
On a completed project the buyer may fund a revision. You get scoped upload/redeploy until they accept or access expires. Submit a corrected ZIP or GitHub snapshot, verify it, then confirm revision delivery. When they accept, you assign ownership of that revision the same way as the original.