-
-
A fixed JSON A baseline keeps original requirements separate from later requests, protecting both parties from scope disputes.
-
After discussion, both parties separately confirm the same fixed document; added services remain new work, not casual edits.
-
A returned delivery stays visible; the contractor records a correction, the client reinspects, then explicitly accepts.
-
The PDF holds agreed scope; the ZIP keeps returns, corrections, and acceptance as delivery evidence. The platform does not arbitrate.
-
Separate client and contractor sessions; admins manage accounts and service health without app-level access to private cases.
Inspiration
The idea came from discussions I saw on Threads about how freelance work is becoming increasingly competitive in the AI era. Low-priced services can leave clients and freelancers with different expectations about maintenance, revisions, and the scope of delivery.
I wanted to build this software to help both sides align on requirements, service scope, and acceptance criteria upfront, reducing information gaps and friction as they work together.
The demonstration uses a fictional Taiwan NT$199 one-page website offer to make that expectation gap concrete. Taiwan and NT$199 describe the background only; the product has no country or currency default.
What it does
The client first records their requirements. The contractor proposes the service scope, exclusions, fees, and acceptance criteria. Both parties discuss and revise any differences, then confirm the same version before reviewing the delivery item by item. If an issue is found, the delivery is returned for correction. After reinspection, the client explicitly accepts the result. Both parties can download the PDF and evidence package at the end.
The client saves a fixed requirement as JSON A. An invited contractor records scope, exclusions, fees, responsibilities, and acceptance criteria as JSON B. Both parties separately confirm the same saved candidate. Silence never counts as acceptance, and new work starts a separate proposal.
How we built it
I used the official six-step workflow and a question-and-answer process with AI to clarify the requirements. After reviewing and confirming the scope, PRD, spec, and checklist, I had AI implement the project according to the plan. I was responsible for deciding the scope and checking the interface and actual user journey. Whenever I found cropped pages, connection interruptions, or outdated descriptions, I requested corrections and revalidation.
The current build is a local, English-only proof of concept using Python, Flask, SQLite, Jinja, JavaScript, JSON Schema, ReportLab, and SVG. Server-side checks control access to private cases and fixed downloads. The running workflow uses deterministic rules; an LLM does not decide contract terms, confirmation, or acceptance.
Challenges we ran into
The main challenges were designing the UI layout and supporting multiple rounds of discussion between the client and contractor. During implementation, I also had to watch for errors that could break the connection between the frontend and backend or cause features to display incorrectly.
I regularly asked red-team reviewers to recheck the project, test all buttons, and conduct multiple visual reviews. I also sought external help to refine the layout, keeping pages compact and information together without overwhelming the user.
Version-bound confirmation and an append-only delivery history were important: a revised proposal must not inherit an earlier confirmation, and a correction must not erase the original return.
Accomplishments that we're proud of
What I am most proud of is how the Skill Pack helped turn a plan that could have been rushed into a structured process. It helped me organize an idea drawn from a social issue and build it into a working MVP. As AI rapidly changes freelance work, freelancers and new clients can have very different expectations, especially about ongoing maintenance. This system gives them a shared process for clarifying those expectations and approaching the work with mutual respect and a willingness to collaborate.
The proof of concept now follows one complete synthetic case from scope clarification and bilateral confirmation through delivery return, correction, reinspection, explicit acceptance, and evidence export.
What we learned
I learned the value of structured planning. When I plan something, seeing one idea often makes me think of another feature to add, and the plan can easily lose its structure. The six steps helped me think through likely challenges and map out the architecture, from the basic functions to problems that might arise during development. They helped me narrow scattered ideas into a project I could actually build.
What's next for Service Requirement Blueprint
Next, I want to make the product available online for free and see how people use it in real projects. If it helps people reach actual agreements, I may later explore a SaaS model. I would keep payment processing outside the product. Only after a real project succeeds would I consider a fixed percentage fee, rather than charging for each conversation. I welcome feedback, including detailed suggestions for improving the workflow.
The current release is a local proof of concept, not a hosted service. It has no payment processing, escrow, or platform adjudication. The saved documents are a traceable record, not a claim of legal enforceability or permanent retention.
Source code and project documentation: https://github.com/jiarong0423/service-requirement-blueprint
Demonstration video: https://youtu.be/D5lQzvLHDhw
The video uses synthetic case records, illustrations, product footage, and inspected document stills. Delivery-test entries are demonstration records, not independent proof of a deployed client website.
Log in or sign up for Devpost to join the conversation.