My name is Sergey Nikonenko, and I am going to tell you how we created a fundraising website, gathered hundreds of sponsors in a single service, built a convenient search, and let the project live on its own.
A client of a client is my client
We always knew that social links were important. The Accelerist case confirmed this theory because our former clients referred the project owner to Purrweb.
Let me tell you how it happened. Somewhere in American business accelerator, Brittany Hill, CEO of Accelerist, came across guys from Wedy, for whom we developed a service for the organization of weddings. They told her about their experience of working with an IT company from Russia and offered themselves as a mediator between Purrweb and Accelerist.
The project got a development team and two project managers. Our project manager worked with the in-house team, the onefrom Wedy was in direct communication with Brittany. We were solving all the problems through the middlemen from Wedy. Our team consisted of 3 developers, UI/UX designer, and 1 QA engineer.
Texas fundraising
Fundraising service Accelerist is a Texas startup that helps non-profit organizations raise money from commercial organizations. In other words, Acceleris is an online fundraising platform. NPO can find sponsors through filtered search, send them an email, and directly communicate with profit-making organizations. There are hundreds of benefactors in the Accelerist database, all of them are donating money into various spheres — from supporting african tribes to saving dolphins in the Pacific ocean.
How Accelerist looks like
Fundraising site Accelerist had existed before we came to the project, but it had been working unstable. The previous contractors wrote buggy code, the user flows were inconvenient for NPO representatives. The service was not as popular as it might have been since commercial organizations had to register on the platform. Not every company wanted to spend time and money, so there hardly was a variety of NPO sponsors to choose from.
We were to build the code, create a high-quality UI/UX design, and enhance user flows.
User flow 2.0
Accelerist works with sponsors and benefactors. To ease the process, we developed a new scenario: profit-making organizations don’t need to register on the platform to be listed on Accelerist, unlike in the old user flow. The information about them is taken from the databases and presented as cards. This way, we get all the organizations that have ever done charity work on top of ones that were registered on fundraising site Accelerist.
That’s how we changed user flow for non-profit organizations:
- NPO signs up.
- Chooses filters to find commercial companies.
- Gets a list of companies with major data about sponsors.
- Adds the best ones to ‘Favourite’.
- Sends a pitch built with a template to potential sponsor’s email.
What on Earth is a pitch
A pitch is an automatically generated letter from a non-profit organization to a representative of a commercial company. Information is pulled from the NPO’s profile: users don’t have to fill in the name, address, and contacts manually. The pitch structure is also arranged in the template. In the end, the user gets a ready letter.
Pitch template
As told by Dribbble
The client provided us with low-fidelity wireframes. Valerian, Purrweb’s UI/UX designer, analyzed them and came up with an idea for the high-fidelity version. Brittany Hill sent text descriptions of each unit, and the designer processed every page: structured the data based on information architecture principles. Our design decisions relied on user priorities and UX patterns existing in similar services.
Fundraising site Accelerist had brand colors: blue and wine red. We got rid of the garish red color and used a pale one. The client didn’t give any other references, so the designer went to Dribbble, Behance, Pinterest, and Awwwards to get inspired.
There is nothing better than airy, light, and minimalistic interfaces. We decided not to reinvent the wheel: the designer chose several references and underlined best practices. It was important to make a UI design that would help users solve the problem without attracting too much attention to itself.
Accelerist became the only my project that the client made little edits on
We got a plan and held to it
For fundraising site Accelerist, we chose our traditional tech stack: Node.js for the backend and React for the frontend. We didn’t strive for using something chick — on the contrary, we used reliable and tried-and-true tools.
So, we had a plan for all the development stages:
- App architecture.
- NPO authorization.
- Amazon S3 services (cloud services that help store images and send emails).
- NPO profiles.
- Sponsors pages.
- Authorization for admin of the platform.
- Favorites.
- Customized filters.
- Payment & subscription.
New stage — new features. Some processes went hand in hand when we built the fundraising service. For example, while one developer was building admin authorization, another one was working on authorization for NPOs. We always split responsibilities, because several developers should work in parallel. It helps to avoid disputes and test a ready part of the product faster. The sponsor pages were the hardest and the longest task. Integration with ZoomInfo is a story on its own. Telling soon😉
Tinder for NPO
We need to talk, Karen. Why did you build Tinder again?
We are proud of the Accelerist filtered search. A non-profit organization chooses several items from the Mission list and defines Sustainable Development Goals on the registration stage. For instance, ‘the shelter for homeless animals’ is a mission assigned to ‘Animals and shelters’, and its goal is ‘Life on land’. And if a commercial organization chooses the same parameters….
Boom! It’s a match!
And not just a match, but a match with a compatibility assessment. The assessment is built upon two criteria. The first one is automatically loaded data about a sponsor company: how much money it can donate, what missions and goals are chosen, what realms it had invested in earlier. The second is NPO data filled in through the check-boxes by its representatives when registering: a mission, a goal, how much money is needed.
Favorite companies
We created the matching algorithm based on unique formulas given by the client. Brittany Hill is experienced in charity work, and even calls herself ‘the leader in the sponsor search technologies’. She provided us with the formulas she created, and we worked out the backend logic.
We were getting the data about sponsors from ZoomInfo, recording it to our database (PostgreSQL), and comparing it with info from NPO profiles. If at least one point coincided, the NPO was matchds with a commercial company.
There was a range of points that could coincide: for instance, CSR focus (Sustainable Development Goals) or location. The more positions were matched, the higher the score was. The maximum result was 1235 points.
The higher the score, the more likely an NPO would receive money from a sponsor. I wish we could add such a feature to Tinder🙃
3 features we said ‘Goodbye’
Less is more. Quality rules.
Being a contractor, you don’t have to implement all the features a client wants. Sometimes, it’s important to explain that end users don’t need some functions. Perhaps they are difficult or expensive to develop, or there are no technologies in the world to implement such functionality.
At Purrweb, we strive to be involved in the product creation, not just implement the clients’ ideas. And if something seems illogical, we don’t keep silent but get into the conversation to find out whether certain functions are needed in an app. We don’t always end up cutting out features, since the client may have a long-term plan that we just didn’t know about. But in the case of Accelerist, we put away some illogical want-tos and saved the budget.
Let me tell you about several features that could have been added to Accelerist.
1. Likes for likes
The client wanted to add likes. They would work like on Instagram: the user can like a favorite company. The number of likes would be displayed on the organization’s profile. But as each sponsor donates to the exact realm,there was no big sense in evaluating companies by likes. We decided to remove ‘likes for the sake of likes’ — instead of them, we added ‘Favorites’ which contained sponsors handpicked by a particular NPO.
2. Complicated search
We implemented a filtered search, but the client asked to add a ranking system for each parameter. For example, the ‘Gender’ filter is important for an NPO for 10 out of 10, and the ‘Manufacturing’ filter — for 5 out of 10. It even sounds confusing 😄 In the end, the client agreed that it was long, expensive, and unnecessary.
Ranking for filtered search
3. Sync with the old platform without authorization
Accelerist already had a platform, and we made certain links of the new version that led to the old one. The client wanted a signed-in user to be automatically authenticated in both old and new systems. But we couldn’t enter someone else’s database, so we, even in theory, could not make the user log in into two systems at once. So we created links only to text pages where registration was not required.
Manual integration with ZoomInfo that made us break the deadline
If I had known that everything would turn out like this, I would have allocated a year for the database. Everything worked fine, besides it.
To receive information about sponsors, we decided to use ZoomInfo. ZoomInfo is a platform where you can buy data on US and Canadian companies. Each request cost money — it was paid by the client.
At Purrweb, we had developed a ZoomInfo competitor with the same feature set. We offered the client to use it, because in the team were developers who had created the application, and they knew it like the back of their hand. But the client chose ZoomInfo instead — the service allegedly made a unique offer for Accelerist.
The client’s desire is the law. But for us, it became the biggest problem of the project.
We had a plan for working with ZoomInfo:
- Request data from ZoomInfo.
- They provide API — access points that allow to retrieve data and put it into our database.
- Launch a company data retrieval worker.
- Put received data into the PostgreSQL database.
- Launch a worker to obtain data on a particular company.
- Put received data into our database.
- Launch a worker to receive possible contacts. We don’t get an email or phone but make sure the company has an email.
- Add new information into our database.
- Launch a worker that receives email contacts.
- Fold the contacts to our database.
When we began sending requests, we realized there was a problem. We thought it would take us a maximum of two or three requests to get information about each company. However, in reality it turned out to be up to 30. New information — new request:
- Name of sponsor’s admin
- Name and contacts of organization
- Sponsor’s location
- Can we send an email
- Email address
One more problem appeared later: names in the ZoomInfo database did not match the actual company names. For example, Amazon was written as Amazon.com, that’s why the script didn’t understand that it’s the same company. That’s why we decided not to pick the data via API. Moreover, we wasted more time. After all, if the API doesn’t work, the data comes as excel spreadsheets, and we need to make a new script for each of them. Our developers wrote so many scripts that it would be enough for several projects.
As you remember, the client was paying for every request.
The data about sponsors
For sure, Brittany was hardly happy about that fact. We stopped making requests and decided to look for an alternative way. Instead of sending a million API calls, Brittany Hill purchased the entire ZoomInfo database. This way, we got all the information in an Excel document. However, there was a thing: the ZoomInfo database is always updated, and all new data goes to all integrated platforms. But obviously the Excel spreadsheet doesn’t have any renewals so in the beginning Accelerist won’t have up-to-date information about the commercial companies.
However, that was the client’s decision made to save the budget.
We wrote a script to parse the information from the Excel spreadsheet and changed the field types in our database to fit them with what we received from the service.
The script was not perfect at once. When it read and picked up the information incorrectly, we fixed, tested, and corrected. Fixed, tested, and corrected.
Where the information about sponsors goes
The main goal of fundraising website Accelerist is to make NPO life easier, so the sponsors’ cards should be informative. Each card has three sections: Business Product Description, Social Impact и Customer Demographics. I’ll tell you what each section includes and what problems we solved to fill them.
Business Product Description
The main information is here: names, logotypes, official revenue, administrator contacts. That is the data we were getting from ZoomInfo through blood, sweat, and tears. It is automatically loaded from the PostgreSQL database based on that Excel spreadsheet.
Social Impact
This section contains types of investments, sustainable development goals according to the UN agenda, the amount of money a company can provide to a non-profit organization, and links to charitable programs. SI is filled in manually by the Accelerist admin.
Customer Demographic
The CD contains information about the sponsor’s audience: gender, age, ethnicity, political views, and interests. The data for this section was taken from the SpotRight service — we also received it as an excel document. The document is uploaded to the platform by the Accelerist admin, and we send the necessary information to the frontend in the form of a pie chart. It wasn’t difficult to create algorithms for this task: SpotRight provided all the data, and we easily made a chart out of it.
Business description on Accelerist
To monetize charity
The monetization system of Accelerist is simple and complex at the same time. On the one hand, payment is made directly, the customer and the admin contact each other via mail. On the other hand, there are tariff plans, but even we didn’t understand how they work. 😁 There are some plans, but the user still has to agree with the admin on the final cost.
Let’s puzzle out together:
Who pays?
Non-profit organizations.
For what?
The main features — search with filters and sponsors’ cards are available only when the user buys a subscription.
How pays?
Payment proceeds outside of the platform. Users are redirected from the payment page to the mail — they discuss the price with an admin. There are 4 tariffs including different feature sets, but the final sum is still negotiable.¯\_(ツ)_/¯
Anyway, Accelerist uses a reliable as a swiss watch monetization method: where is the money – there are the features.
Let it go, let it go
For Brittany Hill, we designed and developed the app in 5 months. The project started in September 2020, and cost her $49,400. We faced no problems at the design stage but the developers had to work hard, especially at the end of the project.
The database with information about users which we made based on the Excel spreadsheet from ZoomInfo will not be updated yet. If a company updates its email, phone number, or name, it will not be changed on the platform. The responsibility for updating the data is taken up by the platform administrators.
What have we learned on the project?
- Keeping in touch with former clients is cool;
- Things may go wrong even with a trusted service;
- Estimating a project before starting the work is important but circumstances can play against you.
- Stay positive, work as a team, and everything will be fine 🙂
A month before the end of the project, Brittany Hill told us that we broke up. We prepared a UI kit, tech documentation, and handed the project over to her internal team. Accelerist started with Purrweb in Russia, and is now developing somewhere in Texas. Sometimes I spy on them on LinkedIn. Recently I found out that Accelerist was ranked 106th in Inc. 5000 Regionals — a list of the fastest-growing organizations in Texas. We are proud of our project. 🤗
