How we work
A product company runs on decisions: what to build, what to leave out, when to launch and how to look after what has already shipped. This page explains how we make those decisions.
Before the code
It has to show up in more than one place and cost real time or money today.
If a spreadsheet does the job well, we don't need a product.
We have — or can build — the technical expertise required.
The product has to pay for its own maintenance. An abandoned product is worse than no product.
If the only way to make it viable is to compromise privacy, the answer is no.
Lifecycle
A problem shows up again and again, at different companies, solved manually or poorly.
Public: Nothing public yet.
We talk to the people living with the problem, study the alternatives and test whether software solves it better.
Public: Sometimes, research notes in Updates.
A minimal internal version to validate the riskiest part — technical or usability.
Public: Lab, with no final name.
The approved prototype becomes a product: final architecture, security, privacy and operations.
Public: Product page with the In development status.
First external users, with close follow-up. Scope and limits are published.
Public: Beta status, active changelog.
Product in operation, with support, a status page and continuous improvement.
Public: Available status, documentation and access.
Improvements driven by real usage and by feedback from users. Every relevant change goes into the changelog.
Public: Changelog and release notes.
If a product stops making sense, we give advance notice and offer a way to take the data out.
Public: Discontinued status, migration guide.
Privacy
Every piece of data we collect has a documented reason. No reason, no collection.
Data has an expiration date. The default period is the shortest one that lets the product work.
We know — and can explain — which services touch each piece of data, including AI models.
Nobody accesses customer data by default, including our own team.
This site measures its audience without cookies and without storing IP addresses: the anonymous identifier changes every day.
Requests for access, correction and deletion come in through the contact form with the subject Privacy.
After launch
Every relevant change to a product is recorded with its date, product and type.
Each product shows what stage it's in. We don't announce as available what is still being built.
Changes that break integrations or alter data policies are announced before they take effect.
Products in operation have public availability monitoring.
Frequently asked questions
No. Devx is a product company: we build and maintain our own software. If you have a problem you think one of our products could solve, we want to hear about it — but we don't sell custom development.
When a product opens for Beta, the announcement goes out in Updates. If your use case closely matches something in development, write to us through the contact form with the subject Product.
Devx is Brazilian and its products are designed with the LGPD (Brazil's General Data Protection Law) in mind, but they are not restricted to Brazil. Availability by region is listed on each product's page.
Privacy is a design requirement in every product. Each product publishes its data use, retention and processing policy before accepting external users.
Openings, when there are any, will be posted in Updates. You can also introduce yourself through the contact form with the subject Other.
Use the contact form with the subject Privacy and describe the issue without disclosing it publicly. We handle security reports as a priority.
It could be the starting point for our next product.