EN
English Magyar
WordPress Custom development Docker Blog Contact
English Magyar

Custom development

We build web applications for the part of your business that no off-the-shelf product covers. The starting point is intrapp.io, our own business operating system, not because it is the only way we work, but because it removes the work of building the same foundations a second time.

final class OrderApproval{    protected array $steps = [        'submitted' => Reviewer::class,        'approved'  => Warehouse::class,    ];    public function onApproved(Order $order): void    {        $order->reserveStock();        $order->notify(new ReadyToShip);    }}

Where enquiries come from

Situations that may sound familiar

Most enquiries start from one of four situations. None of them begins as a software question: somebody simply notices that the work is going slower than it should.

  • Outgrown spreadsheet

    A spreadsheet carried the process while only a few people worked on it. Now many people open it, everyone has saved their own copy, and at closing nobody can say which row is the true one. The formula is not the problem: the work built around it grew larger than it.

  • Systems that do not talk

    Invoicing lives in one, projects in another, stock in a third. The route between them is held in one person's head, with exports and emails. While that person is working everything is fine; when they take leave, the process stops.

  • Done by hand

    There is a sequence somebody works through every morning: copy data, check it, send an email, update a status. No single step is hard, but together they take the day, and the work the person was actually hired for is what gets dropped.

  • Off-the-shelf, almost right

    They bought it, they learned it, and it does work. It is just that their most important process does not fit inside it. Around the remainder they either build a spreadsheet or bend their own operation to the software. Both cost more than they look like they do.

If one of those sounds familiar, the first conversation is about whether writing software for it is worth it at all. Sometimes it is not.

The problem

The problem with starting from zero

Most of a custom business system is the same in every project. Before anyone writes a single line about your actual work, somebody has to build:

  • permissions and roles, down to the field level
  • users, invitations, password resets, sessions
  • company and organisational data, multiple entities, multiple sites
  • audit logging: who changed what, and when
  • notifications by email and in the application
  • search, filtering, exports, reporting

All of it is time and money spent before anything specific to your business exists. All of it has to be tested, secured and maintained afterwards.

public function update(User $user, Order $order): bool{    return $user->can('orders.update')        && $user->company_id === $order->company_id;}// Down to field level: the margin is visible to finance only.protected array $hiddenFor = ['margin' => 'finance.read'];

None of this is visible to the person who commissioned the system.

The foundation

What intrapp.io is

intrapp.io is a BOS: a business operating system. It is the layer underneath a company application (the permissions, the users, the organisational structure, the logging, the notifications, the search), already written, already in production, already carrying real companies' daily work.

When we build on it, development starts at the part that is actually specific to your business: your process, your terminology, your rules, your integrations. That is the part worth paying a developer for.

  1. what we write for you

    • your processes
    • your terms
    • your rules
    • your integrations

  2. intrapp.io: already there

    • sign-in
    • users
    • permissions
    • company data
    • customers
    • audit log
    • notifications
    • search

  3. runtime

    • Docker
    • CI/CD
    • backups
    • monitoring
return [    'auth'      => ['roles', 'permissions', 'audit'],    'users'     => ['invite', 'profile', 'sessions'],    'reporting' => ['export', 'schedule'],    'workflow'  => [],];
The empty module is the one we write for you.

What that changes

The project does not begin with an empty repository. On day one the permission model, the user handling, the audit trail and the notification system are already there and already tested, so the first thing you see is your own process, not a login screen.

It also changes what the budget buys. Instead of paying twice (once for the foundations and once for the business logic), the work goes into the part that differentiates you. And because the foundation is used across projects, a fix or a security update reaches your system as well, rather than being written a second time from memory. It is the same habit that shows up in our Docker work: anything that can be written down once does not get done by hand twice.

intrapp.io is not a requirement

We take on any custom web development, with or without intrapp.io. A public-facing application, an integration between two existing systems, an API, a data migration, a Laravel project someone else started and left unfinished. All of it is work we do.

If your project does not fit intrapp.io, we will say so at the first conversation, not halfway through the build. Which one is better is no secret either: if the system has internal users, with roles and an audit trail, intrapp.io is an advantage from day one. If it is closer to a public-facing surface or a tool written for one narrow purpose, it is not, and we start from an empty repository.

How it runs

The team is complete: design and front-end are in house, so you do not need to line up a designer or a front-end developer alongside the project.

The four stages are not a project-management ceremony. They exist so that at the end of each one you have something in your hands that you can look at, and decide from whether this is going the right way.

  1. Conversation

    You describe what the system has to do and what exists today: what you work with, where the process stalls, who would use it. We say whether intrapp.io fits, roughly what shape the work would take, and also if we think it is not worth starting. This conversation costs nothing.

  2. Assessment

    We go through the process in detail: screen by screen, role by role, integration by integration. At the end you hold a document covering the scope, the constraints and the estimate, broken down so you can see what each part carries. From there you can also decide what stays out of the first round.

  3. MVP

    The smallest version that is genuinely usable goes live first. Real users, real data, a real deployment, not a demo. This is the point where you stop looking at a plan and start looking at your own system.

  4. Iteration

    From there we extend in short cycles, guided by what the users actually hit. At the start of each cycle you say what comes next. Every release is deployable and reversible: if a direction turns out to be wrong, you do not have to live with it.

References

Systems we built and also run

A few examples from our work. We developed each of them and we hold the runtime as well, so they run in containers, on infrastructure described in code, with automated releases.

The Rentiago booking screen at the first of four steps, where the pick-up location and date are entered.
The Rentiago booking flow: four steps, several languages and currencies, built on our own framework.

From your side

Who owns the code, and where it runs

What we write for you is yours. You get the source code together with the repository and its history, continuously, not as a zip file at the end of the project.

  • the code written for the project: yours, without restriction
  • intrapp.io as the foundation: licensed to you for as long as the system runs
  • the accounts: servers, domain and services registered in your name
  • the write-up: architecture, deployment and backup in the repository, not in someone's head

If our paths part, you should not have to ask us anything. The environment is described in files, so another team can build it: that is exactly what the work on the Docker page means when you look at it from your side.

Where it runs is your decision: on our infrastructure, at a provider you choose, or on your own servers if your rules say the data cannot leave the company. The architecture is the same in all three cases, and moving is not a rewrite.

What it costs to run afterwards

The price of a system does not end at handover. It is better said at the start than discussed a year later, which is why our proposals list the build and what follows it on separate lines.

It has to run on something: a server or cloud, a database, storage, backups. That line grows with usage, and it can already be estimated during the assessment, because by then we know how many users and how much data are involved.

It has to be maintained: security updates for the framework and the runtime, the dependencies, the certificates. This is the part that gets skipped when nobody owns it, and turns into a large job later. intrapp.io makes it cheaper here: a fix is written once and arrives in every system built on it, yours included.

And it will keep growing. A system in use always attracts requests, because the company changes too. You do not have to hold a budget for that, but it is worth counting on, and how much of it happens stays your decision, not ours.

When not to choose us

Sometimes the honest answer is that you should not work with us. We say it at the first conversation, while it is still free, not halfway through the project:

  • If an existing product covers your case. Off-the-shelf software that many companies use is cheaper and better tested than anything we would write once, for you.
  • If what you need is a campaign site or a webshop. That is a different trade, and there are people who do it better than we would.
  • If you need a native mobile application in the stores. We write web applications that work on a phone, but we are not the ones who will be publishing to the app stores.
  • If the process that would be covered is changing inside the company right now. Development does not settle that argument, it casts it into code.

We say no to these not because the work is uninteresting, but because a project started in the wrong direction costs both of us more than an order that never happened.

Tell us what the system has to do

A few sentences are enough to start: the process, what you use today, and the deadline you are working to. We will tell you whether we are the right company for it.

Get in touch