When somebody tells you what they built, the useful part is the address. Everything else is description.
An address is the one piece of a case study you can check without asking us anything. It either loads or it doesn’t.
That matters most if you’re deciding whether work like this is safe to put in front of a client. A screenshot won’t tell you that, and it can’t be checked by the person you’re trying to convince.
So here are two addresses. Both of them load.
Two addresses, one product
ineed.software is live. It presents as a software marketplace, and it’s in English.
katalog.software is live too. It’s the same marketplace in Czech, on its own domain. The page declares itself Czech in its own markup: <html lang="cs">.
Both were built using TalkIDE.
These are two separately deployed sites at two addresses. It isn’t one site with a language switcher. Open either one and you won’t find a toggle or a locale selector. Neither site links to the other, and nothing on either page tells you the other one exists.
Two separate addresses is the point rather than an omission. It’s what makes the second one its own running site instead of a locale file inside the first. It also means this post is the only place you’ll see the two connected.
Go and check both before you read the rest of this. The argument here is that you can.
Everything below is about how the two came to exist. If a sentence here can’t be confirmed in one of those two tabs, then it’s a statement about our own process rather than about the products.
Why there are two
ineed.software was built with the intention of being a multi-country or multi-language software marketplace. That intention was there from the outset, before any code existed.
Read it narrowly, because it’s a statement about how the product was scoped and nothing more. It doesn’t say the marketplace operates in several countries or serves several markets. Two deployments in two languages is the whole of what exists, and both of them are one click away.
What it does say is that the second language wasn’t a retrofit. The product was meant to have more than one from the start, and the Czech site is what that intention looks like once it’s running.
That’s the part worth taking away from this page. Most statements about how something was scoped are statements about a decision nobody outside the project can see.
A product decision either shows up in the running software or it doesn’t. This one shows up as a second address you can open in a second tab.
We built it. We don’t run it.
TalkIDE built ineed.software. We don’t run the marketplace, and who does isn’t ours to publish.
So this post stays on the part we did, and everything it asserts about the two products is something you can confirm yourself in the two tabs you already have open.
We’re not naming anyone else involved and we’re not describing the arrangement. Don’t read anything into that. The software is the part that’s ours to talk about, and it’s also the part you can check.
How it got built
It went through the standard path, the one TalkIDE runs by default.
The business team goes first. Vera runs the requirements conversation and Nora, the Business Analyst, works out the plan details behind her. Remy builds a clickable mockup and Otto, the Maintainer, deploys it, so what comes back is something you move through rather than a document you approve.
Then the user triggers the hand-off. It doesn’t happen because a conversation ended.
Mara’s IT team takes it from there. Iris, the Analyst, turns the plan into requirements somebody can check off. Theo and Eli build the backend and the frontend in parallel. Nia reviews their work. Kai deploys the application.
Scoping and delivery are two separate teams, joined by that one hand-off.
TalkIDE builds on Spring Boot with Kotlin, Vue.js and PostgreSQL, and what comes out runs locally in Docker, with multiple hosting options.
That’s the path this project followed, and it’s as far as we’ll narrate it. We don’t have a per-step record of who did what on this build, so we’re not going to write one. One build we did document closely is an admin panel with roles and JWT, built start to finish in 97 minutes.
The path and the result are what we have. The result has two addresses.
How long it took
About one day, from the initial idea to a fully functional application.
That clock is wall-clock, start to finish. It’s elapsed, and it counts the stretch where a build was running with nobody watching it.
Roughly an hour of that went into shaping the clickable mockup.
Both language versions were built the same day. They were released on different days.
That’s what this one project did. It isn’t a turnaround we quote, and it isn’t a promise about the next project.
The other one you can open
BJJ.onl is a live training-diary app for jiu-jitsu practitioners, built with TalkIDE and deployed to its own domain. It’s the other project on this blog you can go and use rather than read about.
Start your project
Two addresses, one product, both live. Open them, then decide what you make of the work.
If you want something of your own that people can open, there are two ways in: start it yourself, or have the first stage built for you.