IP: you can say you'd retain copyright ownership but grant them an non-exclusive perpetual license to use an instance of the software.

Definitely define support terms, e.g. I usually include 6 weeks of critical bug fixing in the price, with an hourly rate agreed upon for any out-of-scope work (unless it's a huge change, which would probably warrant a new proposal). Hourly rate for any other minor work (even bugs) 6 weeks out.

Payment: in my freelance web work, I've always asked for 50% up front fee, with the final 50% due after the work is complete and up to spec (but before launching to production). I've found these are usually acceptable terms, esp. for work under 25k~. Sometimes I can't get away final 50% paid before launching to the public, but I'll remain firm with it if I don't completely trust them.

Milestones are great. But 5 payments seems like a bit much, esp. with an institutional client like a university, which tend to be a pain to get paid by. You want as little bureaucratic busywork as possible, which means you make more per hour for the same flat fee.

Thanks - that was really helpful.

Pick a revenue model [0]

Pick a pricing method [1]

Pick a licensing strategy [2]

[0] https://taprun.com/revenue/

[1] https://taprun.com/methods/

[2] https://taprun.com/licenses/

Few tips:

1. Create a contract traditionally called "Statement of Work" (SOW). Google it and you will get plenty of samples. If absolutely needed, get a lawyer to review if the budget is worth it.

2. Ask for upfront deposit. I ask for 50% but it could depend on your negotiation skills. If a client is not willing to put at least something upfront, then they are not a good client. Most likely, they will nickel and dime you.

3. Discuss the IP upfront. If client wants full exclusive ownership, your price should cover that. If you want to retain ownership but license it out to client, make that clear and reflect in your price.

4. Write the "scope" of the project as clear as possible. The scope defines the "what". The "hows" can vary a bit but try to ensure the client is clear on "what" is being delivered. Google "scope creep" if you are not sure about this.

5. Setup milestones by time and scope items. For each milestone, make sure the client pays. This will ensure that the client is serious and stays on track. If there is no milestone based payment, client could go missing. In worst cases, they may just drop the whole thing. Better to know sooner than later.

6. Be very clear with the client. If an answer is "No", then don't sugarcoat it. Say No. Saying No upfront is 100 times better than saying No later when client expectations are different.

Most importantly, build trust with client but make sure they respect your time and skills.

I strongly recommend making your estimate fill the timeframe you specified, break that down into what salary you would want and then bill hourly, every two weeks.

Do not base it on milestones unless it is something you have built before and "could do it in your sleep" because otherwise you are going to trip on a bunch of "gotchas" and at some point either you or the client are going to be frustrated and/or forced to renegotiate.

It's their IP if they are paying for it. If you develop it without payment it's your IP.

Actually if you spell it out in your contract or master services agreement you can retain rights to the majority of the project for re-use. This is pretty common, most projects are modular and you can save them and future clients cost by re-using similar portions of code.

If they don't like this, then quote them a larger price if they don't want you to re-use their code in the future. Be careful not to give up your rights to create quiz apps for future clients or a possible future SaaS.

You'll want too include something like this, so they are clear you have the rights to re-use parts of their project on future projects. I would include wording that covers the quiz format/process in Type B as you might want to roll your own quiz SaaS app someday.

I am not an attorney, so have your's review prior to using.

4.4.2 "Type A Deliverables" shall mean Deliverables that are specific to Client's Business, including, but not limited to logos, images, unique business logic related source code and documentation associated therewith. Examples of Type A Deliverables include custom graphics and unique business logic code.

4.4.3 "Type B Deliverables" shall mean Deliverables that are not specific to Client's Business, including, but not limited to front end and back end code, framework modifications, tools, methodologies, plug-in and third party source code and documentation associated therewith. Examples of Type B Deliverables might include HTML, CSS, javascript, jQuery, Ruby/PHP Code, Objects, UI Features, App Features, CRUD interaction with objects, sorting, filtering data, search, manipulating data, patches and enhancements to open source frameworks and libraries, open source plug-ins available from third parties, contributions to which are generally-accepted practice in the open-source world. Along with standard features and functionality that are common across websites and web applications.

4.5 Ownership

Except as otherwise set forth herein, the entire right, title and interest in to Type A Deliverables, are the exclusive property of the Client. Under no circumstances may Consultant use the Type A Deliverables, or any component part thereof, for its own benefit or for the benefit of any third-party. Consultant grants the client a perpetual right to use and modify Type B Deliverables. The consultant reserves the right to use, reuse, modify the Type B Deliverables on past, present and future projects.

That's the default in the US ("work for hire"), but the parties can agree on a contract that has different terms.