Not sure what you have in mind here as far as "something you should do". Much depends on the design of your database and your "user base". A runtime solution distributed to many different users? A single copy of your database hosted on a server? A single database file or "split" Data separation system? One file for every table?
Lot's of final design issues to look at--especially any accounts/passwords you may need to set up for your users. And the design of a database system is unlikely to ever be "finished" until there are no longer any users using it. You'll be making ongoing updates to the design as you listen to feedback from your users and adapt it to better server their changing needs.
It's also a good idea to get at least one or two other people to "test drive" a copy of your database before going live. One of the most profitable days I spent years ago was working for one day as cashier using a database system I had designed. (A crime had been committed on the job site and the defense attorney's subpeoned all the regular cashiers as witnesses when the perpetrator was finally brought up for trial.) By the end of the day, I had a to do list of adjustments to the cashier interface to make it easier to use and less prone to user error.
You may find this thread helpful if you are interested in a data separation design: Convert to Seperation Model