Alexander H. Black

FutureTech Industries

My very own agency - start to finish

My Role

Lead UX/UI and Frontend designer, owner and operator of 5 man company

Tools Used

ES2015, React, React Native, Figma, Sketch, Adobe Creative Suite, JIRA, Trello

Project Duration

January 2017 - March 2019

FutureTech Industries


  • Owner and Operator of a company of >5 employees and contractors and averaging 175k revenue
  • Worked with clients to establish project requirements for custom development and operations services and personally lead design and development of the chosen solution(s).
  • Designed and managed 3+ products at any time ranging from data science and analytics dashboards to consumer applications
  • Managed Scrum, Agile, and Google Design sprints


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 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.

Notable Work

Snow Removal Price Verification

The Project

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.

Workflow diagram of the project

Project Structure

Team and Project Management

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:

  • Property Managers - List all properties they have, dates of previous services, and any upcoming services. - Review, manually approve, and dispute invoices. If disputed, they would state the reason and suggest changes. - Request, confirm appointments, reschedule, mark as paid, and create recurring jobs with vendors - White-label the application - Early wireframes

Early wireframes

  • Snow Removal vendors - Reject, accept, schedule, and reschedule jobs - See list of appointments in a day view and a week view - Submit itemized invoices and edit them if disputed - Set payment terms and include payment information - The platform did not support paying through the platform - this was discussed as a v2 feature as property managers or vendors had their own preferred payment platforms that would have proven difficult to convince them to switch from.

Early wireframes

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:

  1. We allowed them to submit an invoice as a csv file and the text was extracted for verification. Vendors could also go to the web app and fill out a form. We did not reach a point of user-testing this to see which was easier for them, but it was something we had planned.
  2. Upon loading the app, Vendors would immediately be presented with a chronologically sorted list view all of their jobs for the day, so they could quickly plan their days and move between jobs. Vendors could select a job to see any details about the job, the address, the contact info, last service dates and approval and payout status.
  3. Before the list, flagged invoices would be presented so they could quickly see why it was being disputed and quickly respond. The dispute process was not handled internally, it would open their email app with their contact’s address pre-filled and a link to the disputed invoice. Facilitation of the dispute was a planned v2 feature.

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.

Completing the Project

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. and the Tsunami Warning System

The Project 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. had a number of strenuous design restrictions - for example:

  1. Design choices had to be implementable with IE 9+, as this was a government website that needed to work for the majority of American users.
  2. Nothing that interacted with the backend could receive more than a visual change, which meant numerous components that would have benefited from having their information architecture redone would stay as-is..
  3. As this was a government site, they didn't want anything fancy. We had to keep the visuals fairly sane, and just make everything more usable.
  4. No frameworks were allowed -everything had to be possible in vanilla HTML, CSS, and JS.

Completing the Project

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:

  1. Supporting IE9 and sticking with vanilla HTML, CSS, and JS often forced us to rethink a number of design decisions or effects, as well as surprising us with how many features nowadays are handled by CSS3.
  2. 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.

    1. We were also able to make copy changes and add helper text to the "untouchable" components to make them more clear.
  3. The site was almost entirely a UI enhancement due to the nature of the restrictions we had in front of us, and major UX changes were more challenging., However, the areas where we could improve the UX included tweaks to information architecture, changing certain form elements used (checkboxes instead of dropdowns), and reducing the overall site scope by combining some pages that could reasonableybe merged into one.

Blockchain as a Service Platform

The Project

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:

  1. They were going for another round of funding and the billing platform was critical for this
  2. There were potential federal contracts on the table

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:

  1. Integration with 2 different services handling calculation of VAT and usage costs
  2. Stripe integration, as well as a direct payment option
  3. A specialty client portal where certain clients could be invoiced on net-15, 30 or custom intervals intervals

Completing the Project

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.

Like what you see?

Let's work together

Reach Out