Building a Web App for Your Nonprofit Without an Internal Team?

So you want to build a web app? For nonprofits without internal dev teams, there are special considerations that make both the process of choosing a development team and the development process itself more complex. Where a company with a profit motive can run with an idea as long as they can justify the ROI, the calculus for a nonprofit is often more complex. This makes the runway to getting a web app project off the ground longer.

At a mission-driven organization, folks from many different departments may be very connected to the outcome of your web app project. This means more people in meetings, more opinions on features and functionality … you get the idea.

This abundance of voices in the room can lead to a lot of false starts. To get your team on the same page from the jump, here are three things to think about when you’ve identified that you want to build a web application.

To RFP or Not to RFP

One particularly tricky aspect of building a web app as a nonprofit is the hoops you may have to jump through just to get your project started. Many nonprofits use a request-for-proposal (RFP) process to select a vendor, which is often an ineffective way to choose a right-fit development partner.

Asking an outside agency to submit an elaborate proposal without understanding your organization’s internal culture and processes doesn’t work very well. You need to start a conversation, not just amass a bunch of proposals from companies you barely know.

Though the RFP process may be less than optimal, it does force you to carefully articulate your project’s goals and requirements, which is something you should do anyways. Make sure your team is aligned on the project’s purpose before you start talking to agencies.

Three Considerations to Kickstart Your Web App Development

Gathering all the different ideas about features is the fun part. But before you let your head float into the clouds, be sure to go through the following basic steps to ensure your project starts off on the right foot.

1. Establish a realistic budget

Living in the nonprofit world, you already know funding has … complexities. Sometimes money comes in a one-time lump sum, other times it’s spread out as cyclical funding — and sometimes grants have a firm cap or other strings attached.

Even if you have ample funds at your disposal right now, building a successful web app is not a “one-and-done” process. There are maintenance and upkeep costs to consider, as well as the potential for additional feature development down the road. If you burn every penny on the initial development, you might end up with a buggy or incomplete app in the wild with no immediate way to fix it. And, perhaps more importantly, you’ll miss the important opportunity to iterate on the initial idea as feedback comes in.

Talk to the folks with the purse strings about the funding you’ll need beyond the initial phase. Explain to them that software is an investment that needs to be maintained and supported over time. If possible, have them commit to a cyclical budget to support your new application.

If the budget for your project is modest and truly finite, you might need to consider dialing your scope back, or even postponing the project. You’re better off scrapping the project than trying to do it on the cheap.

So as you prepare your budget, consider future expenses as well as immediate ones. Realistic, holistic budgeting is the first step to building an app that will be a success for your organization.

2. Pick your tech stack first

After establishing your budget, the next step is to choose what tech stack you’ll build in.

Development firms tend to sort themselves by tech ecosystem, so choosing a particular stack has the side effect of narrowing your search right off the bat. This is a good thing. On the flip side, if you don’t choose a stack before you start the search process, you’ll be choosing from literally every firm in the world. That sounds stressful, doesn’t it?

You can start to narrow down your tech stack options with these factors:

The capabilities of your internal team. What your team already knows can and should influence what tech stack you choose, as well as how you build and maintain your application.

Even if you don’t have a full-blown development team, you might have people with some programming ability or understanding of the software development landscape. Ask around and see if anyone in the organization has a strong tech stack preference, and if so, explore that option. If you have an IT group, find out if anyone there has knowledge in a particular tech ecosystem. Any of the popular tech stack options are likely to work fine for your app, as long as you pick a good agency. In the end, your organization has to own the app, so allowing existing internal preferences to sway the decision makes sense.

If there’s no internal opinion, choose Laravel. If you end up having to hire staff to maintain your app, standing up a development team is more manageable in Laravel than in any other stack. Plus, Laravel is just plain awesome (yes, we’re biased).

Your ability (and funding) to maintain your app. After building the app, your team will be responsible for maintaining it, which means you may find yourself needing to hire one or more engineers. Though elite developers in every stack are hard to attract and retain, the ubiquity of PHP and the massive popularity of WordPress have created a “minor league” for Laravel development. This means there’s a bigger pool of talent to hire from. PHP developers are also somewhat less expensive to employ than developers in the other popular backend ecosystems, further bolstering the case for Laravel.

For reference, here are the average salaries of mid-level developers across popular tech stacks:

• Laravel developer salary: $91,000
• Rails developer salary: $119,000
• Node developer salary: $116,000
• .NET developer salary: $98,000
• Python developer salary: $113,000

If hiring is out of the picture, there are other options for bolstering your team with dev experts that can lead and help maintain your web app, like our embedded development teams.

3. Relentlessly prioritize your feature set

Last but not least, you should spend some time figuring out which features of your product are a “must have” and which you could potentially live without. Relegate anything you can live without to the “nice to have” pile. The more features you push for, the longer development will take, and the more it will cost.

For each feature you can’t live without, take some time to consider how you might be able to scale back its fidelity rather than getting rid of it entirely. That way, when things end up taking longer than you’d hoped, you’ve got a Plan B ready to go.

For example: your app requires a calendar. It’s a must-have feature. But does it have to be an interactive calendar with automated notifications and an interface that allows external users to book meetings? Maybe not. Maybe just a visual calendar that lists events over time is perfectly functional for your users.

Start With Purpose to Build a Web App Successfully

When it’s time to start planning your web app, it’s easy to get overwhelmed. The search process alone can seem like the starting line of a marathon when you haven’t been on a run for months.

But considering each important factor will give your team direction. From there, you’ll have the ability to start searching for a partner to help you build an app that meets your needs, serves your users, and extends your mission.