Update your website by sending a message.
TypeToDeploy lets a non-technical person edit the content of a professional website from a Telegram conversation. Each change is automatically checked, committed to the source code, and published.
- One usernon-technical, on her own professional site
- One production sitelive, edited by the agent
- Every changeproduces a verifiable commit on GitHub
The problem
A modern website is fast, well-indexed and cheap to host because it is built as code rather than in an editing tool.
The trade-off is direct: its owner cannot change it. Updating a price, a date or a photo means going back to a developer.
In practice these sites stop being updated, the information becomes wrong, and the site stops doing its job.
This project came from a problem we had
Lisa is a coach and trainer. Her site presents her work, her services and her prices. She could not change it herself: every update went through Taras.
We built the missing tool. Lisa is now the first user of TypeToDeploy, on a site that is really live.
The solution
No interface to learn, no account to create, no dashboard. The tool sits in a channel the person already uses.
- 1
You write
A message in plain words: “change the group class price to €45”.
- 2
The agent prepares the change
The model finds the field concerned in the site content and prepares the exact change to apply.
- 3
The change is verified
An automatic check compares the declared scope with the change actually produced. Anything outside that scope is refused before it is written.
- 4
The site is updated
The change is committed to the code repository, the site is rebuilt and published. A confirmation comes back in the conversation.
See the system work
A full demo: a message sent, the change verified, the site updated.
What is built today
Each item below carries its real state. Nothing is shown as finished if it is not.
| Item | State |
|---|---|
| Receiving and interpreting plain-language messages | Working |
| Editing site content (structured fields) | Working |
| Automatic scope check on every change | Working |
| Commit to the code repository and automatic deployment | Working |
| Confirmation message and undo of a change | Working |
| Full traceability of model calls | Working |
| Use by a non-technical person on a production site | Tested |
| Use by several people outside the project | To validate |
| Editing site structure and layout | Phase 2 |
| Business model | To validate |
The core technical point: stopping the agent from changing what it was not asked to change
A language model writing directly into the source code of a live site is a real risk.
In the first trials, instructions in the prompt were not enough: the model changed fields outside the request, and justified the decision in its reply.
The answer is not a better instruction but a deterministic check. Before anything is written, the system compares the fields actually changed with the scope the agent declared. If they do not match, the change is refused and nothing is written.
That check is what makes the tool usable on a real site rather than in a demo.
declared scope: tarif_cours_collectif
changed fields: tarif_cours_collectif, horaires_studio → refusedWhat still needs to be validated
The prototype works. The demand does not yet. These are the hypotheses we want to test, and how.
| Hypothesis | Method | Success criterion |
|---|---|---|
| A non-technical person does update their site more often once the barrier is gone. | Tracking update frequency over 8 weeks with a first group of pilot users. | A clear, measurable increase on the previous period. |
| The first customer is the site owner: freelancer, small organisation or association. | Qualitative interviews with owners of professional sites. | A majority say they regularly give up on an update because of the effort involved. |
| Or the first customer is the agency or freelance developer maintaining those sites. | Qualitative interviews with web agencies and freelance developers. | A majority name small client changes as a frequent, barely profitable load. |
| The scope check is enough to allow use without technical supervision. | Adversarial testing: ambiguous, contradictory or out-of-scope requests. | No out-of-scope change written. |
| There is an acceptable price for this service. | Price testing with the people interviewed. | To be set after the interviews. |
The two segment hypotheses are shown together on purpose. We do not know which one is right, and the interviews are there to decide.
Phase 2 — from content editing to site editing
Today the agent edits structured content. The next step is letting it edit the site itself.
- Step 1
Extend the scope check to the source code, not only content fields.
- Step 2
Allow adding and changing sections, pages and layout, with a preview before publishing.
- Step 3
Allow connecting the tool to an existing site that was not built for it.
Each step depends on the one before. Reliability comes before scope.
Who this is for
Freelancers, small organisations and associations that have a site and cannot pay a developer for a ten-minute change.
And upstream, the agencies and freelance developers who maintain those sites: small client requests are frequent, hard to schedule and barely profitable.
The aim is not to replace a content management system, but to make a site editable that today is not.
The team
Two people, two distinct roles, and a project born from our own need.
- Project lead
Lisa
Coach and trainer. She designs and runs programmes in communication, group facilitation and outdoor practice.
Her professional site is where the project started, and she uses the tool daily. She owns the user relationship, the validation interviews and business development.
- Technical co-founder
Taras
Four years in software development and machine learning.
He designed and built the whole system: the agent, the scope check, the repository integration and the deployment.
The tool’s user and its builder are on the same team. Every limit found in use goes straight back into development.
What the Pépite programme would bring
The prototype is built and works. What we lack is not technical.
- Access to test users — freelancers, small organisations, associations — to check our hypotheses in real conditions rather than in-house.
- An outside view to decide between our two segment hypotheses and to build a business model. That is our main area of uncertainty today.
- A working frame and a regular review rhythm, alongside our own activities.
- Funding for hosting, model calls and the time spent on the pilot phase.
Contact
- Agent-driven site
- taras-and-lisa.com
- Product repository
- github.com/taras-svystun/taras-and-lisa
- This site’s repository
- github.com/taras-svystun/typetodeploy-site