Vebses builds custom web applications in Tbilisi, including marketplaces, booking and rental platforms, structured catalogues and internal tools. Not a site that describes your business: the system it runs on, where people log in, records change state, and the process is enforced instead of remembered.
A website presents information. A web app does work. If people log in, if records change state, if permissions decide who sees what, or if money moves inside it, you are commissioning an application, and it needs a data model, not a page structure.
Nobody. Everyone sees the same pages.
Staff, customers or partners, each seeing a different slice.
The content, when somebody publishes.
Records: a status, a stock level, a booking, a price.
Not a question the site has to answer.
The whole design. Who approves, who edits, who can only read.
You get an enquiry and take it from there.
Payments, invoices or deposits happen inside the system.
Most projects that reach us as a website request have an application hiding inside them. If all four answers came out on the left, you want a marketing site or a headless CMS, and we will tell you so on the call.
Where the work leaks today, and what a custom web application does about it.
Discovery is longer here: we map the process before we price the build.
Fixed scope per phase, so a platform can start small and grow on evidence.
You own the code and the database from day one.
A site here, a spreadsheet there, a CRM nobody updates. Every pair of tools needs its own bridge, and the person maintaining those bridges is usually somebody re-typing numbers by hand.
One place where the data actually lives, and every surface (the public site, the phone, the back office, the reports) reading from and writing to that same place.
Four crops from applications we built, each read back literally, and each with the limit of what it proves printed next to it, in the same size type.
What this shows
What it does not show
One floor in its hover state. In the page itself, floors with nothing left are drawn as disabled shapes, but this crop cannot show that, and whether those three units were still free on the day is the client's data, not ours.
What this shows
What it does not show
The list under the plan, where each free unit appears with its area and price, is outside this crop. The colours are the client's convention; we are not claiming which state each shade stood for on the day of the capture.
What this shows
What it does not show
This is the new Copter Tech shop on its preview address, before launch; coptertech.ge still runs the old store. Prices and stock come from a catalogue snapshot, so read it as a search that works, not as today's stock.
What this shows
What it does not show
The spec fields are not one schema yet: one card gives 449 cc and 30 kW, another 75 horsepower and 693 cc. The labels are translated; the units are not normalised. No cart or checkout appears, so this proves a catalogue in two languages, not transactions.
Everything above is cropped from a build we made and captioned with what is literally on screen. Where a build is not live yet, or a screen cannot prove a claim, we said so.
Custom software is the right answer less often than agencies imply. Here is how we decide, including the cases where we tell you to buy something instead.
When a proven product already covers the workflow, and the workflow is not what makes you money.
When a platform gets you most of the way and what is missing is a connection, not a product.
When the way you work is the thing you compete on, and no product models it.
Tell us the workflow on a call and we will name the product we would buy instead, if one exists. That answer is free and it happens more often than you would expect.
Two sides who need different things from the same record: listings, verification, and the moment a buyer contacts a seller. The hard part is never the listing page. It is the cold start, and we would rather plan for it than ship into it.
Mycorner.ge: named, not screenshotted; the archive holds only its cover.
Availability across a date range, which is a harder data problem than it looks: double-booking, deposits, handover and return, and the awkward business of what happens when something comes back late or not at all.
Cars-Rent.ge: pick-up, drop-off, dates and a filtered result set, on its cover.
Thousands of records with variants, filters bound to the values that actually exist, and availability shown as a state rather than a label. This is the shape we have the most captured evidence for.
Deka Development and CFMOTO, both cropped and captioned above.
The spreadsheet's replacement. One place where the rules are enforced instead of remembered, built so the person who does the job by hand today can run it without ringing us.
Mgroup Menu System: a back office feeding a customer-facing menu.
The same standard applies to an application as to a site: measured before handover, not asserted after it.
Lighthouse, mobile
The target every build ships against, verified before launch. Not a promise you have to take on trust.
Thirty minutes. A straight answer and a budget range.
We map the problem and write the scope.
Weekly demos, a staging link from week one.
Live, tracked, and still ours to look after.
Apartment finders, menu systems, catalogues and booking flows, used every day by the people who run them.
Still unclear? The intro call costs thirty minutes and commits you to nothing.
You do, from the first commit rather than at handover. The repository is created in your organisation, and the hosting, database and domain accounts are opened in your name, so leaving is a matter of removing our access, not of asking for a delivery. There is no proprietary framework you would be unable to take elsewhere.
The drivers are how many roles the system has, how many flows carry real value, how many integrations are needed, and whether your existing data is clean or has to be cleaned first. Discovery produces a written scope, a data model, a screen list and a price broken down by phase, and you keep that document whether or not you build with us.
Typically eight to sixteen weeks to a first working version, depending on the number of roles and flows. There is a staging link from the first week and a fixed weekly point where you see working software and make a decision, so the timeline is something you watch rather than something you are told about afterwards.
That is usually the point. In discovery we identify which system currently holds the truth (an accounting package, a POS, a warehouse sheet) and scope each integration once we have actually seen it. Georgian bank card gateways we have shipped; anything else we quote after looking rather than before.
Because the admin surfaces belong to our clients and we do not publish them. What we publish instead is the evidence section on this page: real crops from real builds, captioned with what is literally on screen and with the limits stated. On a call, with the client's permission or on dummy data, we will screen-share one.
Someone who worked on the build answers, on a channel agreed before launch, and a retainer states plainly what it covers and what it does not, so nobody discovers the boundary during an incident. If you ever want to leave, you already hold the accounts, and we hand over an architecture note, the data model and a session with the developer who built it.
Thirty minutes, no pitch deck. Describe the problem and we will tell you what it takes to solve it (scope, budget range, timeline), even if the answer is that you do not need us.
