Application development

We build the softwareyour business runs on.

AndreiTech is a software studio. We build business applications — portals, booking systems, payments, internal tools — and we build them in Ubex, a platform where the database, the logic and the hosting come as one thing instead of three contracts.

What that means for you: no servers to rent or patch, a working endpoint you can call in the first week, and a change to a business rule that goes live the same afternoon. This page explains how that works, honestly, including what it is not good for.

Built in

Ubex

First working endpoint

Week one

You own

Data, logic, source

What Ubex is, in plain terms

Most software projects spend a large part of the budget on things you never see: provisioning servers, wiring a database, setting up deployment, keeping it all patched. Ubex removes that layer. An application is assembled as a graph of connected nodes, and the platform runs it.

• Tables

  The database is already there

  You get real tables with typed columns. No database to provision, no connection strings, no backups to arrange. Each table has an id that the logic refers to, and we keep a written schema next to the code so nobody has to guess what a column means.

• Workflows

  The logic is a graph, published as an API

  A workflow is a set of nodes joined by links: it receives a request, checks who is asking, reads and writes data, calls outside services, and answers. Each one is published as a real HTTPS endpoint with its own authentication, rate limit and timeout — the same kind of API a hand-written backend would expose.

• Interfaces

  The screens are hosted on the same platform

  The front end is ordinary React. Ubex compiles and serves it on its own subdomain or on your domain, so there is no separate hosting bill and no third place to deploy to. This page is one of them.

• Vault & buckets

  Secrets and files have a proper home

  API keys and signing secrets go in an encrypted vault, never into the code. Uploads go into buckets — private ones for documents only their owner may open, public ones for images and video served off a CDN.

Underneath, it is a Go runtime, and parts of a workflow that do not depend on each other run at the same time rather than one after another. That is a design decision you feel as speed on pages that need to pull several things at once.

Where this is the right tool, and where it is not

No platform is right for everything, and a studio that tells you otherwise is selling. Here is the line we actually draw before quoting.

Constraints we design around, openly

• The database does not enforce relationships

  There are no foreign keys or unique constraints. So uniqueness, required combinations and cascading deletes are enforced in one reviewed place in the workflow, and that place is tested. It is more discipline for us and identical behaviour for you.

• The scripting sandbox is deliberately small

  Custom logic runs in a sandbox with a short time limit and no outbound network access. Anything that calls an outside service is its own node, which is a good thing: every external call is visible on the canvas instead of buried in a function.

• Runs are the billing unit

  You are billed per workflow run, not per node, so a big graph costs the same as a small one. It does mean we design bulk work as batches instead of one run per item — a mailing to 500 people is a handful of runs, not 500.

What we build most often

Most projects are a handful of these, joined up. Built together, your bookings know about your payments and your staff see both — which is the part that never works when each piece is a separate subscription.

• portals

  Customer and staff portals

  One way in for your customers, another for your team. Roles decide what each person can open, and the server enforces it rather than the menu hiding it. Adding a role later is a configuration change, not a rewrite.

• scheduling

  Booking and scheduling

  Availability described the way you actually work — opening hours, per-person calendars, breaks, holidays, buffers between jobs. Double bookings are caught before they are written, and reminders go out on a schedule rather than when someone remembers.

• payments

  Payments that reconcile themselves

  Checkout is hosted by the payment provider, so card details never touch your system and the compliance burden stays with them. When a payment succeeds the provider tells us, we verify it against their API rather than trusting the message, and the money lands against the right booking or invoice. Refunds and disputes update the same record.

• email

  Email from your own data

  Confirmations and receipts that fire on the event, not by hand. Campaigns to a list you can segment, sent in batches so a mailing to hundreds of people takes seconds. Unsubscribes are handled and honoured on the next send.

• files

  Documents and media

  Private uploads that only their owner and your staff can open, checked against the record rather than the request. Contracts, reports and identity documents kept where they belong, and images and video served from a CDN so pages stay fast.

• internal

  The admin nobody else builds

  The unglamorous half that decides whether the system actually gets used: dashboards on your real numbers, spreadsheet import and export, bulk edits, and an audit trail that answers who changed what and when.

What actually happens when someone books a slot

This is the level of detail we work at, and the thing a visual platform makes possible to show you. One tap in the browser, one run on the server, seven nodes. Follow the signal.

How a project goes

Four steps, always in this order, each ending in something you can read or click. You are never waiting on a progress report.

1. 01

   Spec

   Days, not weeks

   One written page per feature: what data it needs, what each screen does, who is allowed to do what, and what happens in the awkward cases. This is where a project is actually won or lost, and it is cheap to change at this stage.

   You get: A page you approve before anything is built

2. 02

   Schema

   Before any logic

   The tables, the columns and the rules that protect them, written down and created. Getting this right first is what stops the expensive rebuild three months in, and it is why we will not start on screens before it exists.

   You get: Your data model, documented

3. 03

   Build

   Something working every week

   One endpoint and one screen at a time, each one tested against the live system before the next begins. You watch it come together rather than hearing about it, and course corrections happen while they are still cheap.

   You get: A live URL you can use, updated weekly

4. 04

   Live

   And afterwards

   Deployed on your domain, monitored, documented. You get the keys, the written schema, the endpoint list and a system your next developer can pick up without ringing us — which is the test of whether it was built properly.

   You get: Keys, documentation, and a handover

Systems we have shipped

Anonymised until each client is happy to be named — sector, what it does, and what it is made of. Named references on request.

• Barbershop group

  Bookings, staff rotas and a customer portal

  Walk-ins and appointments in one diary, per-barber availability and holidays, deposits taken at booking to stop no-shows, and a portal where a regular rebooks their usual cut in two taps.

  • Scheduling
  • Staff roles
  • Reminders
  • Payments

• Coffee retail

  Loyalty programme with QR check-in

  Points earned at the counter by scanning a code, rewards redeemed from the phone, and campaigns to regulars who have not been in for a month — with the till staff needing no training beyond "scan this".

  • Points
  • QR
  • Campaigns
  • Dashboard

• Auto glass

  Quote-to-fitting pipeline

  Enquiries arriving from three channels into one queue, priced against a parts list, turned into a quote, and booked into a fitting slot with the right technician — replacing a spreadsheet and a phone.

  • Enquiries
  • Quotes
  • Scheduling
  • Internal tools

• Training academy

  Courses, enrolments and access control

  Access to materials tied to what each student actually paid for, released module by module, with certificates and receipts handled automatically.

  • Programmes
  • Enrolments
  • Documents
  • Payments

The questions we actually get asked

Who owns the system when it is finished?

You do. The account is yours, the data is yours, and the front-end source is ordinary React in your repository. We work inside your workspace, not ours.

What if we want to move off Ubex later?

Then you should be able to, and you can. Tables export to CSV, every workflow exports as a readable JSON file that documents exactly what it does, and the screens are plain React that runs anywhere. Rebuilding the logic on another stack is real work, but you would be starting from a written specification and your own data, not from a black box. We would rather say that plainly than have you discover it later.

How quickly can a change go live?

Changing a rule — a price, a buffer between jobs, who may see a page — is usually the same day, because it is a change in one place rather than a release. A new screen or a new endpoint is days. We will always tell you which of the two you are asking for.

What does it cost to run?

Two things: the Ubex subscription, billed on how many times your workflows run per month, and whatever outside services you choose — a payment provider, an email sender. There are no servers, so there is no cost that grows just because the system exists. We size the plan with you from realistic traffic before you commit.

Is it secure?

The parts that matter are enforced on the server: tokens are verified by the platform before your logic runs, permissions are checked against the record rather than the request, secrets sit in an encrypted vault, and every endpoint has its own rate limit. Card details never touch your system because checkout is hosted by the payment provider. Every change to a record can be logged with who made it.

Can it work with the tools we already use?

If they have an API, yes — that is a node. Payment providers, email senders, accounting, spreadsheets, calendars and messaging are the usual ones. If something only has a CSV export, we build an import for it and stop pretending it is an integration.

What happens when something breaks at two in the morning?

There is no server to fall over, which removes the most common cause of a night like that. For anything else, every run is logged node by node, so the diagnosis starts with evidence. Support terms are agreed before launch rather than improvised afterwards.

Will we be able to understand it without you?

That is the point of the written schema, the endpoint list and the per-feature specs. A workflow is also a diagram, so your next developer can see what happens without reading anyone's code first.