Scrum is overkill, but Agile is more natural for small teams, even one person teams. The point of Agile is laying out a backlog of user stories upfront that accurately describe the client's use cases.
Before the start of each sprint, priority and LOE (Level of Effort or Points) are determined for user stories, and based on what is possible in the 2-3 week sprint timeframe, user stories are added to the sprint.
At the end of the sprint, all the user stories should be developed and tested and the most important aspect of all is that all functionality from previous sprints should be unaffected and the software should not be left at the end of the sprint in a broken state.
Does it make sense to release to the client after every sprint? No, it doesn't and this is a common misconception of Agile that I see all the time. I encounter few clients who want a working release after every sprint. Some may want a release every quarter for instance, and if Agile is being followed, then the last released sprint should always be in a usable state where a release can be prepared for the client on a regular interval. Some clients may also want an environment where they can authorize, demo and evaluate the latest sprint so that they can keep up to date on the real time progress of the project.
What about the challenges of providing software in a usable state within the first few sprints of a fresh new project? The first few sprints of a new project can be a big challenge because the amount of architecture and design work as well as foundation work that needs to occur always peaks at the beginning of a new project and gradually diminishes throughout development.
This can be dealt with in a number of ways, many shops will use the initial backlog of user stories to make and document core architecture decisions before the first sprint even begins. Other times the project is invisioned to be structurally similar to other previous projects and a project template is used that lays out the foundation for the core design and future development. I have also worked on teams where the architecture team starts to kick off the project with a 2-3 week Preamble before the first sprint is officially supposed to begin. The first sprint can start out small, for the developers too, for a typical CRUD application I always like to start off with a login page and authentication. It is easy to start, clearly defined what is finished, and can be clearly tested by QA at the early stages of the project.
EDIT: So how this helps your client is that changes can be made to user stories throughout the process, and this can reflect in modified timelines, estimations, quicker turnaround for the customer, more feedback to the client and more transparency to the client. This benefits you in that you will be more agile in dealing with changes to the original scope in the middle of a project.