When building a new application, you can start coding at the front, you can start coding at the back, or you can approach development randomly and just start wherever. I encourage you to start at the front-end of your application.
I came to this approach a few years ago while working on a new feature of an existing application. In the past, I had always started with the database (probably because my first language was the data-centric FoxPro language).
The new feature required a new database table and several new web pages. My partner and I split up the work: He would write the forms and business logic; while I would create the new table, stored procedures, and data access layer. I immediately jumped to work, creating stored procedures and C# methods. I created procedures and methods to add a row, update a row, delete a row, return a single row by its ID, and return all rows in the table. After a few hours, my colleague was ready to integrate his code with mine. “Where is the method to return all rows matched by last name?” he asked me. This method did not yet exist, so I wrote a function to search by last name and return matching rows. A few minutes later, he asked me for another method I had not yet written, so I wrote that one. After a few hours, I realized I had written almost none of the methods my partner needed and he used very few of the methods I had written in advance.
A light went on in my head: My approach was very inefficient.
The next feature we added, we took a different approach. We didn’t write any stored procedures or data layer methods until we had written code that called these methods. We started with the user interface, which told us which business objects and business logic we need; then wrote those business object classes and business layer code. The business layer in turn taught us what data layer methods and stored procedures we needed to write.
This is the approach I have taken ever since that project. I start with the part of the application closest to the front for which I know the requirements. I use each application layer to define the interface of the layer that it calls. This leads me to write only the methods that I need and ensures that each component has an interface that makes sense to those calling it.
This is the same philosophy used by proponents of Test-Drive Development (TDD), who advocate writing a failing test as the first test.
Starting with the front of my application and working my way back to the database has helped to keep my application interfaces, clean, lean, and logical. It took me a few years to learn this, but my code has improved since I did.