THE PROJECT
G.
Looks after the part you don't see: databases, integrations, servers. Tends to pick well-tested tools even when newer ones exist, because that code will have to be maintained for years.
N.
Looks after the part you do see: screens, flows, how you get from one task to the next. Spends a lot of time watching how people actually use the software, and the outcome is usually that something gets removed.
+
For some things, design, cloud, security, we rely on professionals we've worked with for a long time. They come in on the individual project; coordinating them, and answering to you, is still on us.
DevXX demo — demo data, resets on reload
Close the demo ✕A portfolio you can try.
Each demo is working management software, built by us for a specific trade: doctors, artisans, startups. You step in and work the way a daily user would, with demo data that disappears when you reload the page.
None of them is a closed product: what you see is the skeleton, and from there the flows get rewritten, the look gets redone, and the integration with the tools already in use gets built case by case. If the trade you need isn't there yet, it's next.
→ Four examples below, all of them in the portfolio
“Orders come in on WhatsApp and then someone has to copy them out by hand.”
Management software for food distribution. Stock, orders, delivery rounds, supplier reordering.
Open the demo“They call while I'm under a car, I can't pick up, and they go to someone else.”
Management software for car repair shops. An accepted appointment opens the job, which updates as the work moves forward; the service reminder goes out months later without anyone having to remember it.
Open the demo“If Laura takes her holidays in August, I don't know what deadlines I have in September.”
“Over the counter we sell well. Online we don't exist.”
An e-commerce storefront for a coffee roastery. Catalogue, cart, checkout.
Open the demoWhat happens when you write to us.
The first email
Through the form or by writing to info@devxx.it. We reply within 24 hours and set up a first call, usually half an hour, to understand the problem and tell you whether we can help. If we're not the right people for it we say so straight away.
→ Intro call
We listen to how you work
We come and see how you work, in person or over a video call: who does what, where time gets lost, which tools stay and which go. The exceptions matter more than the rule, because that's where off-the-shelf software gets stuck. At the end you receive a written proposal with timeline, costs, and also what we think isn't worth building.
→ Proposal
The project on paper
We draw the main screens and map the data: which records, which documents, who can see what. Then we decide together what goes in the first version and what waits. It's the right moment to change your mind, because not a single line of code has been written yet.
→ Design
Development, in plain sight
Every week or two we put a new version on a test environment. You try it, tell us what doesn't add up, and we fix it in the next round. That way there are no surprises at delivery, because you've already been using the software for weeks.
→ Development
In production
We bring in the old data, train the people who'll use it every day and go live without stopping the company, often keeping the old system running alongside for a few weeks. Repository, documentation and access are put in your name.
→ Delivery
We stay
Updates, security patches, checked backups, monitoring, for a monthly fee. When a change or a new feature is needed, it's done by the people who wrote that code, with no need to study it from scratch.
→ Support
The part you don't see.
No system is impenetrable, and if someone promises you that, be wary. What can be done is expose as little as possible, keep what is exposed up to date, and find out quickly when a vulnerability comes out in a library we use. We usually know the same day, because every project has automatic alerts set up.
Then there's the simplest rule of all: data you don't collect can't be lost. This site, for one, has no cookies and tracks nobody.
Everything travels over encrypted connections. Sensitive data, health records or passwords for instance, is encrypted on disk as well.
Each user has the permissions their role needs and nothing more. Warehouse staff don't see invoices, and the accountant doesn't edit stock levels.
Automatic backups, encrypted and kept somewhere other than the server. Every so often we actually restore one, because a backup that's never been tried is one you can't be sure of.
Development, staging and production are three separate places. Changes are tried out in the first two, and real data lives only in the third.
The libraries the software depends on are updated regularly, as part of maintenance, and not just when a problem comes up.
Servers are in the European Union. Where the data is, who can see it and how it gets deleted is decided at the design stage, so the processing register more or less writes itself.
Important operations, like deleting a customer or changing a price, are logged with user and date. If something doesn't add up, you can go back and look.
→ None of this gets installed once and forgotten. It has to be kept up over time, which is why it's part of maintenance.
FAQ
Custom management software, ERPs, CRMs, web apps, automations and integrations between systems. The heart of our work is the software that runs the company: orders, inventory, invoices, shifts. We also build websites and e-commerce, but we always start from the processes.