Whoever Starts It, You Run the Project
You want a real piece of software to exist. Logins, roles, records that survive a reload, the thing the work actually runs on rather than a picture of it.
You also want to be the one holding it afterward. That decides who you go through every time the business changes, and it’s a bigger question than it looks from the outside.
There are two ways into TalkIDE. You write the first stage yourself, or you ask us to write it for you. That’s the only thing that differs between them.
The account is yours either way
Whichever way you come in, you hold the TalkIDE account and you’re the one running the project.
That’s the argument of this page, so it goes first instead of last. The entry point is a choice you make once. Who’s driving afterward doesn’t change.
There’s no retainer, because there’s nothing to retain. The project sits on your account and you decide what happens to it next.
Starting it yourself
TalkIDE is open. You sign up and you start.
You talk to Vera first. She runs the requirements conversation, and her job is to ask the things that turn what you want into something buildable: who else logs in besides you, what each of them is allowed to see, what happens to a record when somebody’s account closes.
What comes back isn’t a document to approve. Remy builds a clickable mockup out of that conversation and Otto deploys it, so you’re moving through the screens in the order you’d use them before anybody writes the real code.
When the mockup matches what you meant, you trigger the hand-off yourself. It doesn’t happen because a conversation ended. Mara’s team takes it from there. Iris, the Analyst, writes requirements somebody can check off. Theo and Eli build the backend and the frontend in parallel. Nia reviews their work and Kai deploys the application.
You’re in the chair for all of it. Nothing gets scoped or approved on your behalf.
How much of a project you carry yourself
More of it than most people expect going in. Clients on their own build roughly 80% of the project.
The rest is where engineering support comes in. We’re not going to leave that half-said, because you’d find out later anyway: some of a project needs a hand from us, and you’ll meet those parts when you meet them.
That remainder is the reason there’s a team on the other side of the chat window at all. You don’t get handed the whole job and left alone with it.
If you’d rather we wrote the first stage
Some people would rather hand the first stage over and pick the project up once it exists. That’s the other way in. It’s a branch of the same road, not a different road.
What we build for clients is CRM systems, operations software and websites. Beyond TrainVR.pro and BJJ.onl, both written up on this blog, we’ve delivered those systems for clients too. Every one was built from scratch for the client who asked for it.
The mockup session is free. If that’s the way you want in, book a free mockup session and we’ll scope the work with you.
The build itself is a paid project, and the free part stops at the session. Cost is a hard question to answer honestly, so here’s one project’s receipt instead of a price list. BJJ.onl cost about $592 in credits: landing mock $29, landing build $73, app mock $74, app build $416. That’s one project, itemized. It isn’t a price, a range or a quote for yours.
That first stage is the one part where we’re at the keyboard. Everything after it works the way the rest of this page describes, on your account, with you asking.
What carrying on yourself actually means
This is the sentence people misread, so here’s exactly what it means and what it doesn’t.
A change starts in the chat window. You describe what you want and TalkIDE’s agent team builds it.
There’s no human developer in the queue. That’s the whole of what “directly” means here, and it’s not a claim about how long anything takes.
There’s also no editing surface for you to work in. No page builder, no drag-and-drop screen, no admin area where you move blocks around yourself. If you edit your own pages somewhere today, you don’t get that surface here.
The directness is in the asking, not in the editing.
Nothing skips the team either. A change runs the same loop the build ran: state the requirement, re-plan it, implement it, verify it. Nia reviews a change before it ships, the same way she reviewed the original work.
That loop is the point, not a caveat on it. Software that real people are using is a live system, and a change to it gets treated like one.
And the loop isn’t a diagram. BJJ.onl, a training-diary app we built with TalkIDE, went through 9 concrete revisions after the first working delivery. Every one of them was resolved through that same state-the-requirement, re-plan, implement, QA-verify loop. We wrote up all nine in how change requests run once an app is working, so you can read what was asked for and what came back instead of taking our word for it.
Who maintains the app after the MVP is built
You do, if you want to.
If you wrote the first stage yourself, you never left your own account and the question doesn’t really arise. You carry on the way you started.
If we wrote it for you, you have the option to keep updating that solution yourself in TalkIDE after we deliver it, the same way, by asking. That runs on your own TalkIDE account and your own credits.
Read that twice, because the half-said version of it sells you something we don’t offer. Later changes are yours to ask for and yours to pay for, the same way you paid for the build.
You keep control and you keep the bill. No retainer, and no pretense that changes are free. You also own the code we build for you and you’re free to take it elsewhere.
The option is yours to use or to ignore. You can bring the next piece of work back to us instead.
Start your project
The project is yours to run. That’s true from the first conversation, and it stays true through every change that comes after it.