My very own agency - start to finish
Lead UX/UI and Frontend designer, owner and operator of 5 man company
ES2015, React, React Native, Figma, Sketch, Adobe Creative Suite, JIRA, Trello
January 2017 - March 2019
For 2 years, I ran my own agency, where I led UX/UI design and front-end development, among other things. We worked with a variety of clients of all sizes from small local business and non-profits to startups that had Series B funding and contractors for the federal government. The largest projects we worked on were assisting in a redesign of Tsunami.gov and the Tsunami Warning System, developing the billing platform of a blockchain as a service company, and the full front to back stack of an application designed to verify the invoices of vendors providing snow removal services for property management companies.
After being a contractor for years, I decided it was time to open up my own contracting business with a close friend. While they handled all the back-end engineering, QA, architecture, and any other logic-based development, I led all the UX/UI design, information architecture, front-end development, sales and contract negotiations, and team management including 4 contractors..
The organization ran for two years before I left. In our second year, we reached over $600,000 in annual revenue, and we were on track for $1,000,000 in our third. The largest deal I secured for our organization was a 3 month, $90,000 contract for 2 engineers working on the back-end of an application, which then shifted to a month-to-month, $50,000 per month deal.
We worked on a variety of applications for clients of all services - here are a few of note.
A client that we had a long-standing relationship with approached us to create an app that would allow property management companies to verify the claims of snow removal vendors due to the rampant issue of fraud in the space. Vendors would regularly inflate the number of services provided to charge extra. Based on certain weather data, it could be determined if the services provided were not enough, too much, or an appropriate amount.
The project would enable property managers to see the verified data, dispute it directly with the vendor, or override the warning and approve the invoice if the extra services were acceptable.
The application was a front-to-back development where we designed both the UI and the architecture of the solution. The client also expressed heavy interest in turning this into an application that could verify other contractor services, though these were deferred to simplify v1. This was accounted for in throughout the project.
Our existing contractors were already familiar with the technologies that would be needed, so we didn't need to do any new hiring. We placed two on backend and one plus myself on front-end. The other front-end developer handled working with Django's templating engine and adding function to React components while I handled layout and styling.
We used the same project management structure as the Blockchain as a service application due to the scale of the project and the team and client being entirely remote.
The product had to be designed for 2 user groups with the following needs:
The entire product was designed as a white-label solution by the property manager. They could customize colors and replace certain images such as logos. When a vendor would go to a page for the listed property, the app would switch to that property manager’s styles, and revert back when they left the job listing. This was a big point of contention due to the context switching this was caused, however, this is a feature the client wouldn’t budge on, so we restricted it to colors and images.
For the snow removal vendors, this needed to be incredibly easy to use as most of these were contractors who were just moving in and out of a job. We decided on three major patterns for them:
Property managers had a similar pattern, albeit with more features. They were immediately presented with a chronologically sorted list of invoices submitted, which were followed by a list of properties with currently scheduled jobs, followed by a list of all properties. The items in each list immediately showed if a property had a flagged invoice or approved invoice, to encourage quick action.
When a property manager was reviewing an invoice, they would see the submitted number of services provided, and if there was a discrepancy, the application’s suggested number of services. Property managers would then either contact the vendor to handle the dispute, or manually approve the extra services.
Due to NDA, I’m not able to disclose much, however, here’s what I can say.
Django was chosen to power the back-end for rapid development, selection of CRM’s, customizability, and its templating engine. React was used for the front-end due to power, ease of development, and team familiarity. GraphQL was used over a REST api for efficiency as well as ease of use in JSX.
We sourced weather data from public services and checked the number of services rendered versus a transformed set of weather data to qualify and verify the services. We didn’t poll the API consistently, only for days there was an invoice that needed to be analyzed, and only for the areas related. This was in order to save costs on API calls and storage.
The project was around three months long using the process I discuss (here). We were able to complete this project quickly this way, as there was only a week where no active development could occur.
We never were able to move forward with v2 with them, however, we did end the contract mutually with the client impressed with the final product.
Tsunami.gov was looking to redesign their website, as they had both design and development practices that were out of date. They had already contracted an external team for the design, but were looking to augment the team further. My company was brought in to assist, and I was the designated designer on the contract.
Tsunami.gov had a number of strenuous design restrictions - for example:
There's little I'm allowed to share about the work done due to the design still not being released (if it will), however, what I can say is the following:
A lot of the site had to keep its information architecture the same, however, there were numerous components we were able to improve to lessen the harm of the "untouchable" components.
The client was looking for a team to architect and implement a new billing platform. They were struggling with certain implementation details as well as needing an experienced team to create a fool-proof system. This was important for two reasons:
The development was entirely back-end engineering, so my role was limited to team and project management and client relations.
Some of the features the billing system required were:
I interviewed, contracted, and led a team of 2 python developers to build the billing platform. The team was entirely remote.
The project took about 5 months from kickoff to completion. We held a weekly standup via Slack group call, and had everyone post yesterday's completed, blockers, and upcoming tasks in a Slack group for a daily standup. If a lengthy discussion was needed, the relevant team members would move to a group call.
I held a weekly call with the client to review progress. The client was easy to work with, though there were moments of conflict. One of which was a relationship issue between my team and one of the client’s team members. I organized a group call between the client and my team, and allowed everyone to air their grievances. After the call, there were no more issues, and the project continued smoothly.
The project ended with incredible ease, everyone was happy with the work produced and was excited for the potential future it created.