6 things I learned from building my first app for a client

Recently I built my first app for a client.

A friend of mine who runs a novel-writing contest had mentioned earlier this year that she really liked my last app, and that she wanted to do something similar for the contest at some point, so when I was looking at building a React app in April, I offered to build one for her.

It was a wonderful opportunity to code something fun and writing-related (I am a novelist in my other life), and the fact that it was in use right after I finished was a bonus!

This is what I learned in the process.

1. Set expectations

The first thing I did, even before offering to build the app, was had a conversation with my potential client about what she was looking for and whether that aligned with what I felt I would be able to make with my current skill level—and in a reasonable amount of time. I wanted to make sure I wasn’t committing to do something that either I wouldn’t be able to do, or that wouldn’t meet her requirements.

After this initial conversation, I also wrote out a list of specific website features in plain terms that corresponded to how I would have to set up the code, and then asked my client to confirm, correct, or add to this list. This helped give her an idea of what types of details I needed to know, and when she added to the list, gave me an idea of what exactly I needed to build!

The initial list:

- Secure user sign-up/login

- User has many novels (to make reusable for future years if necessary!)

- Novels include info like: title, summary, word count

- Badges that can be dragged over (or turned on or something) 

- Word count tracker

- Should there be a section for users to see some things about each other, like number of folks participating, etc?

- Some sort of calendar function for days past/days left? (Not sure about setting this one up)

- About page/drop down with a bit of info on what this is/how this works 

- Admin access for you to change some things 


Making sure my client and I were on the same page about what I would and wouldn’t be doing with this app was essential to keeping things moving smoothly and efficiently down the road.

2. MVP

Speaking of expectations, a minimum viable product is also a useful thing to keep in mind, especially for building something for someone else.

Before I began work on the app we also discussed what features were necessary to launch the app and what features could be added on later, or if I had time. This meant I had a clear checklist of features to work from while keeping in mind other things that could be useful for this project in the future.

3. Cultivate the ability to explain your code to a non-coding audience

Early in the process of building my novel progress tracking app, one of the features my client asked for was a word count tracker that let users edit their word count for a specific day and involved a graph to display writing progress over time—something like what the Nanowrimo (National Novel Writing Month) website, which inspired some of my functionality, used.

(Screenshots from my Nanowrimo progress in 2017)

This was something that seemed simple from a non-coding perspective but actually would have significantly increased the complexity of this part of the project.

In the database, I had initially set the novel model to have one wordcount attribute, which users can update on the frontend. Nanowrimo, a 30-day contest, has 30 different wordcount-type attributes, one for each day, and because the contest I was designing the app for ran all year, this would involve creating 365 different wordcount attributes for each novel.

In addition to increasing the amount of data each novel would have to hold, a year’s worth of wordcount attributes would mean finding a visually appealing way for the user to edit each of them—a simple list of that many days wouldn’t cut it.

Though this was completely doable, it would take more time, and the client was eager to have the website up and running.

When altering the word count tracker came up as a requested feature, my ability to explain how much coding work this would be in plain terms—that it would be more like adding an extra feature than making a slight change to an existing feature—meant that my client understood why this was something that couldn’t be added to the first version of the app while keeping the short turnaround time. As a result, she was happy to include this feature on the list of stretch goals instead.

4. Mock-ups help

Even though I only did a quick sketch of what I was thinking the web app would look like, I found this was a great way to get on the same page with my client about what I was building for her. It was also a handy thing to work from when I was building functionality!

5. Working to a deadline is challenging and rewarding

This is one I already knew on some level—my coding projects previous to this one had all been completed in two weeks, these deadlines set by my bootcamp, but while these projects had to pass a certain amount of requirements in that time, they didn’t have to be completely finished and deployed by then.

For this app, I agreed with my client on a deadline of four weeks to have the app deployed and ready for users.


Also, I decided that in addition to building a finished React app with the functionality we had agreed on, I needed to add forgot/reset password functionality by this deadline to prepare for real users. This was something I had never done or even researched before—and so was deploying the app, both frontend and backend, for that matter. But I do love a challenge. I buckled down, did a lot of reading, watching videos, and fixing errors in my code, and on the evening of the deadline, my app was deployed and ready for users.

Overall I found the experience very rewarding: having a reasonable deadline meant something to push myself toward, and the final result of being able to reach the goal set for me was a wonderful feeling.

And speaking of:

6. Seeing your work in use is really satisfying!

Deploying an app for immediate use by multiple users was a great opportunity to think about what was actually needed for user functionality in an app, and also to work with a specific use case that already existed. And the end result of seeing other folks using something I’ve built has reaffirmed why I’m a software engineer in the first place: to solve problems, and to build useful things.

(The version of this app in use by the contest is private; this is a screenshot of my demo deployed with the same code!)

Going forward armed with this experience, I look forward to building many more apps for clients in the future!