Software house for startups, from prototype to product online
We build the app, web app or platform your startup stands on, from the prototype your first users try to the version you put online, with one of your people deciding what comes first.
How do you choose a technology partner for a startup?
By asking first who keeps the code: once paid for, it must belong to the startup, with the documentation and the accounts. Then who works on it. dotenv builds apps, web apps and platforms for startups, with at least two people on every project and a prototype that future users try before the code is written.
A software house, or a team of your own
You can have both, one after the other: work on the product starts with an external team while you look for people to hire, and when your first technical person arrives the product is already up and running. In the ten projects described in our case studies, the teams ranged from two to five people, across design, development of the part that runs on the servers, of the app or the pages the user works with, and project management.
Hiring for those roles one by one takes time, and at the start you may not yet know which profiles you will need in a year. Watching the product grow, you understand better whom to look for.
dotenv is a software house founded in 2020, and between management and team we are 11 people today. Your product goes through the hands of at least two people, and the work is documented in writing.
What the startup keeps
Once the work is paid for, the code belongs to the startup, and with it the documentation and the environments the product runs in. It stays yours even if one day you hand it to someone else.
Also check whose name the domain, the cloud account, the payments account and the app store accounts are in. They are the keys to the product, and they must be in the startup’s name.
Before investing, whoever funds you may ask what is inside the product, who wrote it and who owns it. These are questions you want to be able to answer with the contract and the list of accounts in hand.
The code and the requirements for an innovative startup
Owning the code also matters in law, if you want to register as an innovative startup (startup innovativa) in the special section of the companies register (registro delle imprese) provided for by Decree-Law (decreto-legge) 179 of 2012.
Among the conditions in Article 25 is meeting at least one of three requirements. One of them is holding the rights to an original computer program, connected to the company’s corporate purpose and business activity.
The program must be registered with the Registro pubblico speciale per i programmi per elaboratore (the special public register for computer programs), kept by SIAE, and the requirement holds if the rights belong to the startup, that is, if the code is its own.
What goes into the first version
The first version must handle well, from start to finish, the path a user opens the product for. A rule of thumb: a feature goes in if, without it, the user cannot reach the end of the path.
Then the users arrive. At short intervals we look together, for an hour, at the version that is running, and decide what to do next. That is why you need someone on your side who has the final say, usually whoever founded the company.
The work is split into phases. Before funding the next one you look at the results, and we check with you that what we have built does what was needed.
A prototype to try, before the code
Clickable screens, with the real cases of your product inside. Your first users try them, or the people you would like to become your users, and the corrections are made there, while it is still a design. The approved prototype becomes the specification the team writes the code from.
For a startup the prototype is useful twice: it tells you whether the path holds up in the hands of the people who will use it, and you can show it to whoever funds you before you have spent the development budget.
Even if you stop there, you keep the screens and the design work.
AI inside the product
If your product has to recognise, classify or decide something on its own, ask whoever builds it what they have already put into production. For a buy-and-sell platform we wrote software that reads the listings and decides 80% of them on its own; a person looks at the rest. Also ask where the model runs and where the data it receives goes, because that can change the cost per user and who sees that data. With us, the data goes only through private AI services of our own, never through external services.
We also founded Neurally, an AI company born inside dotenv from an idea of ours, which today has two products. Neurally Platform governs a company’s knowledge, across processes, documents and patents; AREA recognises objects in video streams, live or recorded, without dedicated hardware. Neurally’s people bring their expertise to dotenv’s projects.
Your users’ data
If the supplier processes your users’ personal data on your behalf, the GDPR requires it to do so under a contract that binds it to you (Article 28). So who is responsible for what is put in writing before the product collects its first piece of data.
For a product that collects health data or identity documents, the security rules are decided before the screens are designed, and any rules stricter than the law go into the contract. Decide early, too, who inside the startup can see which data. Our certificates, ISO 9001 and ISO/IEC 27001, can be downloaded from the certifications page, with number and expiry date.
An AI model can also run where the data is: our software that transcribes meetings, used today by a public body, does the speech recognition and keeps the audio on the body’s own servers.
Team, technologies and releases
The team includes a UX/UI designer, a project manager, backend, frontend and mobile developers, fullstack developers, and people who work on AI and machine learning. Christian Ascone is our CTO. If the startup already has someone looking after the technology, bring that person to the meetings where we look at the running version.
All the code is under version control and the build is automated: a release with a failing test stops there. The projects described in our case studies include PHP, Symfony, RabbitMQ, React and a machine learning model in Tensorflow.
What it costs, and how to think about the budget
The price is driven mainly by two things: how big the first version is, and how many external services it has to connect to, such as payments, logins, maps or your suppliers’ systems.
Then there is time. In the ten projects described in our case studies, the duration ranged from two to sixteen months, and for the apps we have built so far, at least two months passed from the first meeting to real use. If there is a date that matters, a launch or a deadline with whoever funds you, tell us straight away.
What comes afterwards goes into the sums too. Servers and pay-as-you-go services grow with the users, and ongoing maintenance needs a separate agreement, which is paid for.
In the form we ask which range your budget falls in. If it is too tight for the product you describe, we tell you on the first call. The items that make up the cost of an app are explained in our guide.
If you still have an idea to test
Sometimes people come to us with an idea, and with the doubt that anyone really wants it. That is why we have From idea to business, a product of our own: eight weeks to a fixed date, a team that works only on that, and from week seven real people using the first version. What goes into the weeks is decided together every Friday.
At the end you have a dossier with the numbers collected, to decide whether to fund the real product, and part of our fee comes only if you carry on. When it is not the right format, for example if the product only makes sense with thousands of users from day one, we tell you before we start.
Before the call
It starts with a call, free of charge, by video too. Then a site visit. It helps to come to the call with:
- The product in a few lines: who it is for, and what it changes for them.
- Where you are: an idea, a prototype, a first version already online.
- If some code already exists, where it is and who wrote it: we take it over.
- A budget range, which the form asks you for, and the date that matters to you.
- Who will have the final say on your side.
How we also work: For SMEs · For enterprises · For the public sector
Frequently asked questions
- Where does the product run?
- On your servers or in a cloud, as you prefer, and getting it running in the chosen environment is part of our work.
- Who can see the code while you write it?
- That is decided in the contract, depending on the work to be done. If your CTO wants to follow it as it grows, ask before you sign.
- Are the connections to external services in the quote?
- Yes. You find out what it costs to connect the product to a service by opening that service up, and it is part of the project quote.
- Do you take over code written by someone else?
- Yes. We start from what exists: on the first call you tell us where the code is and who wrote it, and the first part of the work is decided from there.
- Can we stop after part of the work?
- Yes, at the end of a phase. What has been done stays with you.
- What if a defect turns up after launch?
- We fix it at no cost to you, because it falls under the legal warranty. Response times, if you want guaranteed ones, go into the maintenance agreement and apply during the warranty too.
- Do you take equity in the startup, or work on a results basis?
- We consider both routes, case by case. We talk about it on the first call, together with the product.
Tell us about the product you want to build, and where you are.