Product owner
Defines the user outcome, business rules, priorities, and what a successful result looks like.
MCP & CHATGPT APP DEVELOPMENT PROCESS
From one workflow to a production build you own.
A fixed-scope process with an early working slice, written acceptance criteria, production testing, and complete handover.
One-off projectWorking result before the full buildClient-controlled deployment
Milestone artifactWorkflow map + written proposal01. Scope agreed
Milestone artifactOne complete request connected end to end02. Working slice ready
Milestone artifactEvaluation results + known limitations03. Production checks passed
Milestone artifactDeployment + code + runbook04. Handover complete
HOW THE BUILD MOVES
Prove one complete path early. Then finish it properly.
01.
Stage outcome
Scope the first workflow
We define the user, request, desired result, systems, access model, action boundaries, and feasibility risks. If the workflow is too broad or depends on unavailable data, it is narrowed before the project is quoted.
You receive
- Approved workflow map
- Tool and access plan
- Written fee, stages, assumptions, exclusions, responsibilities, and acceptance scenarios
Review gate
Approve what will and will not be built.
02.
Stage outcome
Prove one complete path
We connect one representative request through the integration to the source system and back. Your team reviews the working behavior before the remaining tools and interface states are completed.
You receive
- Working end-to-end slice
- Early API, data, identity, and permission findings
- Review notes and confirmed next steps
Review gate
Confirm the useful path before the build expands.
03.
Stage outcome
Complete and evaluate the behavior
We finish the remaining tools, account connection, permission checks, safe writes, structured results, optional interface, failure behavior, and logs included in scope. Then we run the agreed evaluation scenarios.
You receive
- Complete scoped implementation
- Repeatable evaluation cases and results
- Known limitations and completed fixes
Review gate
Confirm that the written acceptance scenarios pass.
04.
Stage outcome
Deploy and transfer ownership
We deploy to the agreed client-controlled environment, verify the production path, and transfer the project assets. The responsible team is walked through configuration, operation, logs, rollback, and future changes.
You receive
- Production deployment
- Source, configuration, tests, and documentation
- Runbook and technical handover session
Review gate
Accept the build against the written scope.
MORE THAN A HAPPY-PATH DEMO
We test the failures users and operators will rely on.
Request selectionView examples+
Direct requests, natural or indirect phrasing, similar requests that are out of scope, and cases where no tool should run.
Inputs and accessView examples+
Missing or invalid information, unauthorized requests, incorrect scopes, and cross-tenant access attempts.
Actions and confirmationView examples+
Read, draft, and committed writes, plus confirmation, cancellation, duplicate requests, and partial-action cases.
Dependencies and recoveryView examples+
Empty results, timeouts, upstream failures, retry behavior, and workflows with or without an optional interface.
The agreed scenarios become repeatable evaluation cases that are included in the handover.
CLIENT PARTICIPATION
A focused build needs clear decisions, not constant meetings.
Technical owner
Explains the source systems, identity model, integration constraints, environments, and operational requirements.
Safe access
Provides the documentation, test environment, representative data, and credentials required for the approved stage of work.
Timely reviews
Reviews the scope, working slice, acceptance results, and production handover at the agreed gates.
Production credentials are not needed for the first conversation.
DEPLOYMENT AND HANDOVER
Your team receives a build it can run and change.
01
Code and product assets
02
Deployment and configuration
03
Tests and operating guidance
04
Knowledge transfer
View the complete handover inventory+
Code and product assets
Source repository plus the MCP server, ChatGPT app package, skills, interface, schemas, or other assets included in scope.
Deployment and configuration
Infrastructure setup, environment requirements, dependency files, secrets inventory, and production configuration.
Tests and operating guidance
Automated tests, evaluation fixtures, logs guidance, known limitations, rollback steps, and operational runbook.
Knowledge transfer
Architecture and data-flow documentation plus a live or recorded technical handover for the responsible team.
One-off projectClient-controlled infrastructureNo required KNWN subscriptionOptional maintenance scoped separately
PROCESS FAQ
What teams ask before work begins.
Scope, timing, acceptance, and ownership before work begins.
What happens after the first call?
We review the user workflow, source systems, access requirements, action risks, and desired result. When the project is a fit, the next step is a focused workflow and technical review that gives us enough information to prepare the written proposal.
Do you charge a subscription?
No mandatory subscription is attached to a Studio build. Each engagement is quoted as a one-off project. Hosting, maintenance, or continued development can be scoped separately when the client wants them.
How much does a project cost?
Pricing is set after the workflow and technical dependencies are reviewed. The proposal states the one-off fee, stages, assumptions, exclusions, client responsibilities, deliverables, and acceptance criteria before development begins.
How long does a project take?
The timeline depends on workflow breadth, source-system readiness, authentication, write actions, interface requirements, evaluation depth, deployment, and client review availability. The delivery sequence and target timing are included in the proposal rather than estimated from a generic tool count.
Can we begin without a complete API?
We can review and map the intended workflow, but a production integration still needs a reliable path to the required data and actions. Missing backend capability is identified early, then the workflow is narrowed or the additional backend work is scoped separately.
When will we see something working?
During the working-slice stage. One representative request is connected from the user interaction to the source system and back before the remaining surface is completed.
How is the project accepted?
Acceptance is based on the written scope and agreed scenarios. It is not a general promise that every possible prompt, future platform change, or untested client behavior is covered.
What happens when an evaluation fails?
KNWN records the failure, determines whether it is a defect, dependency problem, missing requirement, or known limitation, and completes the fixes included in scope before acceptance. Material changes outside the agreed scope are reviewed separately.
Can KNWN maintain the build after launch?
Yes. Maintenance, operational support, or new functionality can be scoped separately. It is not required for the client to own or operate the delivered implementation.
What does KNWN need from our team?
A product owner, a technical owner, access to the approved systems or test environments, clarification of business rules, and timely decisions at the agreed review gates.
START WITH ONE VALUABLE WORKFLOW
Show us the job you want to make possible.
Tell us who needs it, what they should be able to accomplish, which systems are involved, and which actions require approval. We will tell you whether it is a fit and what the first build should include.
Discuss your buildSee the KNWN Visibility MCP delivery in practiceUnderstand MCP server budget and scope
No production credentials are needed for the first conversation.