Basic system
4–8weeksOne 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
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.
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 us | What it almost always means | Where 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 |
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.
One process, a couple of roles and simple reports. A request log, visitor control, an internal diary, a quote builder.
Several modules that talk to each other and users with different permissions. It is the tier most projects fall into.
The whole operation inside: multi-company, multi-warehouse, management accounting and dashboards per department.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
An internal system is usually sensitive business information. We would rather leave the space blank than publish something that is not ours to tell.
Stock by location, stock ledger, transfers and stocktaking with a scanner.
Order assignment, live status, customer signature and a WhatsApp notice.
From ticket to site visit, with parts, hours and a sign-off in the field.
Budget against actual, valuations and project progress.
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.
Describing the process in one line is enough for us to start.