Bespoke web systems · Peru

The system your operation already runs in Excel, with the repository in your name.

Software built for your process, not a product you have to adapt to. It is built in two-week sprints and at the end of each you see it running on a test server: you do not wait four months to discover something else was understood. The code lives in a Git repository registered in your company's name from the first commit.

2
Weeks per sprint, with a demo
30
Days of guarantee after go-live
100%
Of the code, in your name
staging.tuempresa.pe · sprint 4
Sprint demo Deployed
Modules delivered6
API endpoints34
Automated tests128
User roles4
Repository Your organisation
Technical documentation Up to date
SUNAT issuing Fastura API
See how it is built

A staging demo at the close of every sprint

Laravel · PHP 8 Your own documented API Deployed onOur VPS

You are probably looking for

Nobody calls asking for "a system".

They call describing an operational problem. This is the translation we do in the first meeting, and the scope comes out of it.

What people tell usWhat it almost always meansWhere to start
"I have everything in Excel and it falls over every month" Several people editing the same file, with no history and no permissions. Nobody knows which version is the good one. database + roles
"My salesperson quotes by hand and gets the price wrong" The price list lives in someone's head and in a PDF from eight months ago. a rules-based quote builder
"I bought an off-the-shelf system and it does not do what I need" The product forces you to change your process, and your process is exactly what sets you apart. discovery of the real process
"The previous developer disappeared" There is no repository, no documentation, and he ran the server from his personal account. code audit
"I need my warehouse and my invoicing to talk to each other" Two systems that do not know each other and one person copying data from one to the other every day. API and integration
"My field team has no signal where they work" Paper forms someone types up at night, two days behind. an app that works offline
"I want to know what I make per project and today I do not" The costs are scattered between the accountant, the site manager and a notebook. cost centre per project
If your case is solved by a product that already exists, we will tell you. Building from scratch something you could buy off the shelf is the most expensive way to start.
Timescales by tier

How long it takes, depending on the size we are talking about.

The timescale is only fixed after discovery, but these three tiers cover almost everything that reaches us. If your project fits none of them, it is probably two projects.

TIER 01

Basic system

4–8weeks

One process, a couple of roles and simple reports. A request log, visitor control, an internal diary, a quote builder.

  • 2 to 4 sprints
  • One main module and its report
  • Login with roles and an audit log
TIER 02

A mid-size management system

2–4months

Several modules that talk to each other and users with different permissions. It is the tier most projects fall into.

  • 4 to 8 sprints
  • Inventory, sales, purchasing or projects
  • An API to connect with what you already use
TIER 03

A full ERP or CRM

5–10months

The whole operation inside: multi-company, multi-warehouse, management accounting and dashboards per department.

  • 10 sprints or more, in phases
  • Migration of historical data
  • Training by department, not one single session
An ERP is not handed over on the last day: it comes out in phases. The first useful phase goes into production long before the project ends, and from then on it starts giving you work back.
Digital Buho SAC · since 2012 Our own development team Our own servers Your own invoicing system with an API A repository in the client's name
Before writing code

Discovery is a deliverable, not a courtesy meeting.

We sit down with the people who do the work every day, not just with management. We map the process exactly as it happens today, shortcuts and exceptions included, because that is where the requirements nobody writes in an email live.

  • Interviews with every role that will use the system
  • A map of the current process and the proposed one, side by side
  • Prioritised user stories: what goes into sprint 1 and what waits
  • Data model and architecture diagram
  • What integrates with what you already have, and how
  • A clickable Figma prototype of the critical screens
  • A fixed scope, with what is out of scope written in the same size type

This is where the fixed price and the timescale come from. Before discovery any figure is invention, and promising you one over the phone would be the project's first mistake.

today's process prioritised stories frontend API database architecture before the first commit
How it is built

Two weeks, one demo. And so on until it is done.

Every sprint closes with the system running on staging and a video call where you use it yourself. What you do not like is corrected in the next sprint, not at final delivery.

interviews data model fixed scope · fixed timescale
SPRINT 0

Understanding the process and fixing the scope

Interviews with the people doing the work, a process map, a data model and priorities. It ends with the scope in writing, the timescale and a fixed price. It takes one or two weeks depending on size.

DESIGN

The screens, before they are coded

A clickable Figma prototype of the critical flows. You walk through it with your team and comment on it. Moving a field here costs minutes; moving it once the module is built costs a sprint.

SPRINT 1…N

It is built and tested

Two weeks of development with automated tests on the logic that cannot fail: calculations, permissions and states. At the close it deploys itself to a test server on your staging domain.

DEMO

You use it at the end of every sprint

Half an hour on a video call with the system running. Not a presentation: you sign in with your user and do the real process. Whatever you note down goes on the list and is prioritised for the next sprint.

GO-LIVE

Production, training and guarantee

Data migration, deployment to production, training per role recorded on video and a written manual. From that day the 30-day guarantee against errors in what was delivered runs.

What you take away

The repository is in your company's name from the first commit.

It is not a final handover in a ZIP. It is a GitHub or GitLab organisation of yours, where we are collaborators and you are the owner. You can look at progress any day.

Repository in your nameWith the full commit history, the branches and the tags of every version that went into production.
Technical documentationHow it installs, how it deploys, which environment variables it needs and how the database is put together.
Your own APIDocumented endpoint by endpoint, with request and response examples. So another system can connect without calling us.
Automated testsOn the critical logic: calculations, permissions and status changes. They run on every deployment.
Recorded trainingOne session per role, on video, for whoever joins your team next year.
30-day guaranteeAny error in what is delivered is fixed at no charge, counted from the move into production.
Your data, exportableDatabase backups and export to Excel or CSV from the system itself, without asking us.
Support after go-liveA block of hours or a monthly plan, with a written response time. It is bought separately and is not compulsory.

"And what if you shut down tomorrow?"

It is the right question and we answer it like this: you have the code, the documentation, the deployment scripts and the server credentials. Any Laravel or React team can pick the project up and carry on. We use no closed tools only we know how to run, and no licences tied to our account.

We have been operating from Lima for 14 years, but the answer cannot rest on that.

And we also sign
  • An NDA before the first meeting, if your information calls for it
  • A contract with payment milestones tied to deliverables, not to calendar dates
  • Assignment of the code's rights to your company, in writing
  • A response-time agreement for the support afterwards
What it is built with

Boring technology that another team can maintain.

We choose tools with a large community and developers available in Lima. An exotic framework leaves you tied to the only person who knows how to use it.

Backend: Laravel and PHP 8

It is our main ground and the one with most talent available in Peru. It brings out of the box what a management system needs: authentication, roles, queues, scheduled tasks and database migrations. For services needing many simultaneous connections we use Node.

Laravel PHP 8 Node.js

Frontend: React, Next.js or Vue

The choice depends on the project. Next.js when the application has a public face that has to show up on Google; React or Vue when it is an internal panel. All in TypeScript and with Tailwind, so the design stays consistent without fighting inherited stylesheets.

React Next.js Vue TypeScript Tailwind

Data and infrastructure

MySQL for most cases, PostgreSQL when there are heavy queries or geographic data. Docker so your development environment matches production, and Git with code review before every deployment.

MySQL PostgreSQL Docker Git GitHub

It connects to what you already have

Almost no system is born alone. If your ERP, your POS or your marketplace has an API, we use it. If it does not, it is solved with scheduled file imports or by reading the database directly, depending on what the provider allows.

REST API Webhooks ERP CRM POS Marketplaces SSO WhatsApp Business API

When the work is out in the field

If your team reads meters, delivers orders or files reports where there is no signal, the application is built to work offline: it saves on the phone and syncs when the network returns. It is more work and has to be decided in discovery, not halfway through the project.

  • A web app installable on the phone, without going through the app stores
  • A sync queue with conflict resolution
  • Camera, on-screen signature and barcode reading
  • If you genuinely need a native app, React Native is considered
What a software factory cannot give you

Your system can invoice and send WhatsApp notices without integrating a third party.

The two integrations most asked for in Peru are electronic issuing and WhatsApp notification. Both are products of ours, with their API and their support in the same team.

ISSUING

Documents through Fastura's API

Your system closes the sale and the document goes to SUNAT from the same flow. Receipt, invoice, credit note and dispatch note, with its signed XML and its CDR. With no separate invoicing system to buy and no two support contracts blaming each other.

  • Issuing from your own backend
  • Tax-ID and national-ID lookup included
  • The document sent to the customer's email
See Fastura's API and source code →
NOTICES

Notifications through Waya's API

The system sends WhatsApp notices when it should: order confirmed, job ready, payment falling due, appointment reminder. One endpoint, not an international provider with support in English and billing in dollars.

  • Messages from your backend
  • Approved templates and a verified number
  • Replies landing in the team inbox
See the Waya API →
DEPLOYMENT

It runs on our VPS

The system is deployed on our servers, with backups, monitoring and an admin console. If something goes down on a Sunday, you write to one WhatsApp and on the other end are the people who coded it and the people who run the server.

  • Separate staging and production environments
  • Backups with their retention stated
  • We also deploy in your cloud, if you already have one
See the VPS range →
Development, server, invoicing and WhatsApp all go on one document under your tax ID. One supplier, not four contracts with four separate renewals.
A professional going through documents and records at their desk
For operations that cannot stop

An internal system is judged on the day it fails at eleven at night.

That is why the project does not end at go-live. The error log stays connected, the backups keep running, the server monitoring stays on, and there is a channel where you write and someone who knows your code answers, not a help desk that opens a ticket.

  • Error logging with an automatic alert when something breaks in production
  • Database and file backups, with their retention written down
  • A permanent staging environment for testing changes before they go up
  • A block of hours or a monthly plan, with an agreed response time
  • The team that built it is the team that supports it
Types of system people ask us for

Named client case studies go up when they authorise it.

An internal system is usually sensitive business information. We would rather leave the space blank than publish something that is not ours to tell.

Inventory and warehouses

Stock by location, stock ledger, transfers and stocktaking with a scanner.

Delivery and routes

Order assignment, live status, customer signature and a WhatsApp notice.

Service orders

From ticket to site visit, with parts, hours and a sign-off in the field.

Costs per project

Budget against actual, valuations and project progress.

This block is reserved for real case studies When we publish one it will carry the company's name, what was built, how long it took and what changed in their operation. With their written authorisation.
Questions

What people ask before commissioning a system.

How much does a bespoke system cost and what does it depend on?
It depends on how many processes are involved, how many different roles will use it and what it has to integrate with. That is why we do not publish a rate: the price is fixed once discovery ends, when we already know what has to be built. Before that any figure would be invention later revised upwards, and that is how projects get ruined.
How long does it take?
In tiers: a basic single-process system, 4 to 8 weeks. A mid-size management system with several modules, 2 to 4 months. A full ERP or CRM, 5 to 10 months and always in phases, with the first useful phase in production long before the close. The timescale is confirmed once discovery ends.
Is the code mine?
Yes, and not at the end: from day one. The repository is created in a GitHub or GitLab organisation in your company's name, you are the owner and we come in as collaborators. At the close we sign the assignment of rights in writing and you keep the full history, the documentation and the deployment scripts.
Can I see progress before the end?
Every two weeks. At the close of each sprint the system is deployed on a test server on your staging domain, and we do half an hour on a video call where you sign in with your user and do the real process. It is not a slide presentation: it is the system running, with test data.
What happens if I change my mind halfway through?
It is normal and the method is built for it. Changes go on the priority list and are fitted into the following sprints. If a change grows the scope, it is quoted separately before anything is touched and you decide whether it goes in now, later or never. What we do not do is slip it in quietly and mention the overrun at the end.
How is it paid, all upfront?
No. It is paid in milestones tied to deliverables: an advance to start discovery, partial payments as sprints are approved, and a balance at go-live. The milestones are written into the proposal with an estimated date for each, and if a sprint slips through our fault, the milestone is not charged until it is approved.
Do you sign NDAs?
Yes, and we sign it before the first technical meeting if your information calls for it. You can send us yours or use ours. On projects with personal data we also agree in writing who accesses the production database and under what conditions.
Does it connect to my ERP or to the system I already use?
Almost always yes, and the route depends on your provider. If it has an API, we use it and that is cleanest. If it does not, it is solved with scheduled file exchange or by reading the database directly when the provider allows it. Tell us which system you use and we will confirm the route before quoting, not after.
Can the system issue receipts and invoices?
Yes, with the API from Fastura, which is our invoicing system. Your system closes the sale and the document goes to SUNAT from the same flow, with its signed XML and its CDR. There is no third party to hire and no two separate support contracts when something fails.
Can it notify my customers on WhatsApp?
Yes, with the Waya API. From your backend you fire the notice when the status changes: order confirmed, job ready, payment falling due or appointment reminder. The number is verified and the templates approved, and if the customer replies, the conversation lands in your team's inbox.
Where is the system hosted?
On our VPS, with separate staging and production environments, backups and monitoring. If your company already has its own cloud or a policy that requires it, we deploy there: we hand over the scripts and the documentation so it runs wherever you decide.
What does support after launch include?
The first 30 days are a guarantee: any error in what was delivered is fixed at no charge. After that you can buy a block of hours or a monthly plan, with a written response time, covering corrections, minor changes, backups and monitoring. It is not compulsory and you can buy it later, when you need it.
If you shut down, who maintains the system?
Any team that knows Laravel or React. That is precisely why we use common technology and leave you the repository, the documentation and the deployment scripts from the start. There are no closed components only we can run, and no licences tied to an account of ours.
Do I have to migrate the data I already have?
It is assessed in discovery and it is almost always worth it. We migrate what is useful for operating and for looking things up: customer and product masters, balances and the history you will actually use. Data kept only just in case goes into a searchable backup, not into the new system, because dragging years of rubbish along slows everything else down.
Request a proposal

Tell us about the process that is eating your day.

We reply within 48 hours with the tier your project falls into, what discovery would look like and what we need from you to start. If we can see an off-the-shelf product would suit you, we say that too.

48 h
For the proposal
Business days
2 wks
Per sprint
With a demo on staging
30 days
Guarantee
From go-live
Short brief

Your project in one minute.

Describing the process in one line is enough for us to start.

We use your details only to answer this enquiry. If you need an NDA before telling us anything, say so right here.

We use your details only to answer this enquiry. If you need an NDA before telling us anything, say so right here.