Creating a Support System

More families than ever are in need of housing, and Family Promise is a non-profit organization based in Spokane, WA that strives to help as many families as they can.

Beyond just housing, people need support and care. Case workers track each family’s progress and build a relationship over time to connect them with resources, work through ongoing difficulties, and eventually find a permanent place to stay.


In order to do their work with a growing team and a growing network of shelters, Family Promise is in need of a support system for their staff to log notes between shifts, manage daily, weekly and long term reporting, and track shelter attendance over time.

I joined the backend team for this project. I was excited and a little apprehensive going in. I was nervous to learn the new codebase, it was already well built out by the previous team. It took some time to acclimate, but eventually the systems became more familiar and easy to work with.


The structure of the project became a little awkward due to the way teams were split up. The app was previously developed by one team, and when their iteration was done, they passed it on to both us and another team. Our team received the frontend, backend and data science repos, along with the environment variables and logins to make everything work. The only problem was, it didn’t work.

So we started to troubleshoot. The backend and frontend teams worked together through many zoom calls to work out our local configurations and get everyone’s installation up and running. We sifted through docs and configuration files and eventually got everyone loading the app.

Then came the sign in. To start, we created our own Okta account to run the user logins for development only, intending for it to be a configurable placeholder that could be swapped out for a stakeholder authentication system later. This was a mistake. Don’t do this, at least not using Okta. We were then directed to use a labs standard account, also meant to be a placeholder. This didn’t work either, and it appeared to be failing in the same ways.

Basically, we had two pieces that worked separately, but couldn’t talk to each other. The Okta user login technically worked, it read the user data and issued tokens that the browser could pick up, and we confirmed the tokens were valid. The database also technically worked, it showed all data populated from its knex files, it could be browsed directly using SQL and a postgres platform (elephantSQL), but it couldn’t validate and remained locked when hooked up to the app or Postman queries. The app depended on the database validating in order to log users in, so there was still no access to the app.

Eventually, it came down to a communication issue between teams. It turns out the only Okta credentials the app would work with were for the account the other team was given. We could use those to log into the app and view the data, but in order to do that, we had to use their deployment of the database, and couldn’t write to it without causing conflicts.

Thankfully, we were able to implement workarounds for Data Science and Frontend teams to be able to build a display-only version for the reporting features they had built out. And they had some great reporting features to show off.

Future Iterations

I would have liked to ship more features with backend functionality, but since we did the work to sort through the authentication issues, the next iteration of the app should be a lot cleaner and hopefully a seamless start up for the next team. I do wish we had gotten to do more coding than configuration, but I’m really proud of my team for sticking with it and pushing through the hours of bugfixes. There were times where I got discouraged, but ultimately we pulled through and figured out some important points for the next team.

If I had another month, I would be excited to add more functionality. The first thing we wanted to get hooked up was the guest check-in form, allowing shelter guests to essentially RSVP for the following evening during the day.

The next feature that would be fun to add would be the reporting functionality. Our Data Science team built out some fantastic interactive reports, and I’d love to see that full interactive capability represented within the app pulling live data from our API, not just the python notebooks.

I’d like to say thanks to our team, we worked hard and everyone pushed hard. My backend team especially really put in the hours when things got tough. There’s nothing we can’t do together, and I’m really glad I got to be a part of this project.

Frontend Developer based in Concord, CA