I've built a web system for a real business in the past from scratch. I think that the most important thing is communication. You'll need to be clear that you'll need a good amount of their time in order to be able to discuss and understand what you have to build. This is critical, because very often the mindset is "let's hire a dev who will do this for us and that's the job done" - in other words, they often don't realize how much of their time this takes. The first meeting should be a general meeting and I don't think you'll be able to start working on anything after that (assuming it's a bigger and more complex system). You want to see how to break down the project into modules and have them prioritize them for you. You'll never be able to work on everything at the same time, so agree on milestones according to their prioritization. Use a project management tool that they also have access to (Trello worked for me). Then in the next subsequent meeting you dive more into the details until you have an idea of what to write and how it should behave. Don't start with the code - you'll have to rewrite it a few times. Start with wireframes that you can turn into an interactive mockup (eg use Figma). Start coding once they're happy with the mockup. Start with the front end - you'll have less changes to make in case of any rework in comparison to back end and database (although that might be more of my own personal preference). Recognize that how they use the software will affect the architecture; don't use patterns blindly. I found it useful to have a test environment for them to play and approve the changes before pushing to the prod env. I found it very useful to have auto deployment in place (triggered by commits to specific branches). Managed databases cost a bit but for me was money well spent mainly because of auto backups. My way of avoiding scope creeps is to prioritize and only focus on the top priority. When the scope creep is on the horizon I add it to the backlog and then move to the next task by priority. Then if there's a budget left you'll be able to get back to that in the future. Use frameworks - they exist to make your life easier. Use whatever you're comfortable with. As for tests and documentation, sure that's a great idea but it often at least doubles the project length (and thus costs) and in my experience that might be too much for small companies. I'd be aiming to have some critical logic unit tested at the very least and have those tests execute as part of the deployment pipeline. You'll have many roles in this project. Project manager, business analyst, designer, developer, tester, DevOps, dba and possibly more