I’m always looking for a way to maximize how much work I can get done with a new app every day. Currently, I’m stuck on this wonderful movie trailer creator, and am totally in awe of how seamless the interface is. And sometimes, it’s a matter of fitting in work around my schedule with auditions, errands, photo shoots, etc… Other times, it’s a matter of how much information I can process per day. There are some days where my brain just can’t process any more, and I have to take that into consideration while my daily schedule can be a flexible one. On a day like today where I can make my own schedule, one of my ideas t0 maximize productivity is to work on the design in the first half of the day, and then implement or prototype it during the second half.

Where am I now in the process?

In the last few weeks, I’ve been working on transferring what I have designed in Adobe XD “mockups aka static images of what I’m visually planning to create” to real-working code. So far, so good! Screens are connecting, and data is flowing. Lately, with every new feature I add to the app, I’ve been brainstorming the ultimate question: “How can I make this feature better?”

The way I see it, when putting together an app there’s the standard way of doing things and there’s the simpler/creative way. I can make this app look like every other database-driven app out there, or I can come up with a customized interface that just makes sense to actors and performers who would use this app every single day to print their resumes.

With my next show coming up, I know from previous experience that I’m going to have to put most of the app work on hold until I have the time to work on it. My intent is to get the app to a point where it is a springboard for me to jump right onto where I left off when I had to set it aside.

What does “springboard app status” look like?

Here’s a list of what I want the app to be able to do before I start my next show:

  • Organize multiple resumes
  • Create and manage credits
  • Have an easily-expandable foundation

Let’s look at these one by one.

Organizing multiple resumes

The app has to be able to start up and show you all of your available resumes at your fingertips. You can then tap one to view and edit its contents. The contents includes your personal information “located at the top such as your name, phone number, email….”, your special skills “juggling, musical instruments…”, and of course your credits.

Create and manage credits

The credits are the most important pieces of data within this app. Users will be spending most of their time adding and organizing them within each resume. Before I leave for the show, the app needs to perform at least some sort of interpretation of credit structure and organization. I say interpretation because I now that none of what this app looks like now will be a direct result of what is shown in the first release. That’s why bullet number three is the most important point.

Having an easily-expandable foundation

There’s a really cool paradigm in programming. The idea is to never have to repeat yourself when coding, and to manage the “behind the scenes” of your app as a pyramid. An example is like this:

To put a credit on the screen, the app has to create a box that the credit goes into. It then adds a space to put text into and then fills that text with the role you played. After that, it adds a new space to put text into and subsequently adds the title of the show you performed in. It then does this for all of the other information you’ve assigned to this particular credit.

If I had to tell the app to do each of those steps every single time I wanted to make a new credit, I’d lose my mind. Instead, I built the app to do all of those things just by saying: “App? Make a new credit with the following role and other properties.” in code.

My main goal before going to my next show is to build up this foundation so that the app is really smart when I come back to it. Not only that it performs well, but that I also has the ability to learn new tricks with minimal teaching effort. If I get an idea for a new feature, implementing it should be an easy task.


To get this app “springboard ready”, I’m trying to design a feature in the daytime while allotting some of that daylight for other daily lifetime necessities and then code it at night. It’s another form of having a plan and following it through. Not every feature I design during the day will end up in the finished product. In fact, most of them will probably go through multiple iterations until it’s just right.

Who knows? Maybe I’ll be able to design and code a few check boxes off of my feature list in a day?

Hooray for documenting!

I’m really enjoying the process of documenting this project. Whether it’s through video, or by writing these posts, I know I’m going to look forward to reading them far into the future. I also hope that these posts can give some insight into what developing an app looks like with one person at the helm. Documenting has also allowed me to lay my thoughts out on “paper”. It gives some clarity to what many-a-time seems like a foggy, ginormous endeavor.

Looking forward to an adventurous, but positive journey.

Leave a Reply