I'm a part-time developer who built a web app for my father's company. Another company, an Italian systems and electrical installation business with about 15 users and roughly €1 million in annual revenue, liked it and requested 19 changes before adopting it. I completed 18 of those changes for free to win the deal.
The app handles daily work logs, hours, travel time, kilometres, multiple clients in one day, jobs, materials, time off, and Excel/PDF reports. The custom work took about 80 hours over two months. Hosting and database costs are around €40 per month, and I handle development, support, and training myself.
A comparable generic product costs about €6 per user per month, or roughly €90 monthly for 15 users, while broader small-business software typically costs €100–€500 per month. A software house might charge €15,000–€40,000 to build something similar, plus 15–20% annually for maintenance. Since this is Italy, I'm trying to account for lower local software budgets rather than blindly applying US pricing.
My current idea is €349 per month, or €3,490 paid annually, plus a one-time €900 setup fee covering data import and one day of on-site training. I was also considering locking that price for three years.
I'm unsure whether to use a subscription/retainer or a one-off licence with annual maintenance. I also need a sensible way to limit support as a one-person business, define when future change requests become billable, avoid creating the expectation that all changes are free, and decide whether a three-year price lock is risky. What would you include in the contract, and how would you structure the pricing?
3 Answers
Don’t promise unlimited support when you have no idea what usage will look like. Start with a defined launch period, perhaps 60 or 90 days, and track every support request and the time it takes. After that you’ll have real data for adjusting the plan.
You could offer a simple base subscription with normal bug fixes and hosting included, then charge separately for feature requests, onsite visits, extra training, urgent response, and work outside business hours. If they prefer buying rather than subscribing, you can still sell a perpetual or fixed-term licence, but retain control of the hosted infrastructure and charge an annual maintenance/support fee. Make clear what happens if maintenance is cancelled, including whether access stops, support ends, or the software continues without updates.
The €900 setup fee seems easy to understand. The €349 monthly price may be viable if support stays light, but it is dangerous if it quietly includes unlimited consulting and development. A three-year lock is also risky unless there is an annual inflation adjustment or the locked price is conditional on a minimum term and timely payment. At minimum, exclude taxes and third-party cost increases from the lock.
The original 80 hours should not be treated as a reason to give away the finished product. The app has value because it replaces manual work and can potentially be sold to more companies. At the same time, pricing it only as 80 hours multiplied by an hourly rate misses the recurring value and the risk you are taking on.
I’d present two or three options: a hosted subscription with setup and annual payment, a higher-priced plan including more support, and a licence or fixed-term option with maintenance charged separately. That lets the client choose how they prefer to buy without forcing you into unlimited obligations.
Your agreement should cover ownership of the underlying software, the client’s data, confidentiality, backups, uptime expectations, termination, payment delays, liability limits, security responsibilities, data export, and what happens if you stop operating the service. Because this involves an Italian business and potentially employee data, have a local professional review the contract and privacy obligations before signing.
Separate the product from the services. The recurring fee should cover access to the hosted application, backups, security, normal maintenance, and a clearly defined amount of support. Setup, data migration, training, custom development, and major changes should be separate line items.
Put a support policy in writing: what counts as a bug, the response target for different severities, how requests are submitted, and how much assistance is included. For example, normal email support during business hours could be included, while training, consulting, urgent work, and feature development are billed at an agreed hourly or daily rate.
Every request beyond the agreed scope should be estimated and approved before work starts. You can explain that the initial changes were part of the launch arrangement, but the production contract uses a different change-control process going forward.
The free changes do create an expectation, but a written scope reset is still perfectly reasonable. Call the current version the agreed launch scope and state that anything new requires a quote or written approval.
The first few months are exactly when support may be highest because users are learning the system. A short onboarding period with defined training is safer than promising a permanent amount of support you cannot estimate yet.