Questions people ask us.

Write to us through the contact form or email hello@archeaxon.com. We reply within two business days and set up a short discovery conversation. After that we map your current process, agree what success looks like, and scope a first phase before any code is written.

Nothing formal. It helps to know who will use the system, what you use today, even if it is spreadsheets or WhatsApp, and what has to be true at launch. We work the rest out together.

That depends on the agreement. Our typical approach is to sign a mutual NDA before discovery discussions when you ask for one.

Sometimes, and we say so after looking. We start with a short assessment of the code, the data and the hosting. If we can take it on, we tell you what we found, what it would take to run it properly, and what we would fix first. If the risk is too high, we say so plainly.

It depends on what you need, so we do not publish prices. After discovery you receive a written proposal with the scope, the deliverables, the assumptions and the price of the first phase. That depends on the agreement, and our typical approach is to price work per agreed phase, so you can pause or stop between phases.

That depends on the scope agreed during discovery. The discovery phase ends with a plan that includes a schedule and the milestones after it. We would rather commit to a smaller first release we can hit than a large date we cannot.

That depends on the agreement. Our typical approach is invoicing per phase or per milestone, with the payment terms set out in the contract before work starts.

Change is normal and we plan for it. We describe the change, re-estimate it, and agree it in writing before continuing. You always know what a change costs before you approve it.

That depends on the agreement. Our typical approach is that, once invoices are paid, you own the custom code we wrote for your system, and the licences for any third-party or open-source components are documented in the handover.

Yes, and we design for it. Handover includes architecture notes, runbooks and environment guides, so another team can run the system without us. We do not build lock-in on purpose.

The source code and repositories, architecture documentation, deployment runbooks, environment and access guides, and your data in open formats. Training for your team is part of launch, not an extra.

That depends on the agreement. Our typical approach is a support agreement that covers monitoring, backups, and a defined channel for problems and improvements. The terms, hours and response targets are written down before launch.

Mostly Next.js, React, TypeScript, Node.js and PostgreSQL on the web, Flutter and React Native for mobile, and Tauri for Windows desktop, with Docker and managed platforms such as Vercel and Neon. We choose the stack per project and explain the choice in plain language.

That depends on the agreement. Our typical approach is managed cloud hosting, documented in writing: which provider holds the application, the database and the backups, and in which regions. If you need hosting in a specific country or on your own servers, tell us during discovery.

Yes, where the work needs it. Counterbase, our point-of-sale system, keeps selling offline and syncs when the connection returns. Offline-first is a design decision we make early, because it affects how data is stored and merged.

Only where they earn their place. The systems we have shipped so far run on conventional, auditable logic: role-based access, workflows and audit trails. If AI would genuinely help your process, we will tell you what it would do, what it would cost, and where it would fail.

Roles and permissions are enforced on the server, where the data lives, not only in the interface, and sensitive actions are recorded. Our security page shows where you can see this in real systems, including the action-level permission matrix in Vendale and the authentication security review on the iACT Learning Platform.

No. Each system is built for its organization. Where a system serves many organizations, like Counterbase, each one is a separate tenant with its own data. We do not use your data to train models.

We are careful here. For the data in your system, your organization is normally the data controller, and we build so you can meet your duties, with consent, access, correction and deletion supported in the design. This website has its own privacy policy. For formal advice, talk to a lawyer. We do not sell compliance.

Tell us. Reports go to hello@archeaxon.com and are handled through the responsible disclosure process on our security page. Problems in running systems are fixed as a priority, and we will tell you what happened and what we changed.

That depends on the agreement. Our typical approach is that only the engineers who need access to run and support your system have it, credentials live in managed environment variables rather than in code, and access is removed when it is no longer needed.

We are based in Nairobi and work with organizations across Kenya and the wider region, remotely and on site where the project needs it. Discovery workshops are usually on site. Build phases run remote-first, with regular reviews you can attend from anywhere.

Yes. Systems we have shipped take M-Pesa (Daraja), PesaPal and Paystack, alongside Stripe where it is useful, and they are built to keep working safely when a provider is down. Payment credentials are configurable and stay out of the code.

Yes. We can provide the documents procurement asks for: a written proposal, a contract with defined deliverables, and formal invoices. Tell us your process at the start so paperwork does not hold up the work.

Yes. Training is part of launch. We train the people who will use the system and the people who will administer it, and the runbooks stay with you afterwards.