Considering Building a Salesforce App? Ask Your Team These 10 Questions

We love to feature guest posts by trailblazers from the nonprofit community. This post will help you if your organization is considering building an app and using the Salesforce platform to design and deliver it. These best practices and insights come from a real-life journey from idea to app — an app called HomeKeeper, which helps nonprofits and local governments manage affordable homeownership programs. This post originally appeared on the HomeKeeper blog and we’re sharing it here since we think it’s helpful!

Ask These Questions Before You Develop Your Salesforce App

If you’re considering building a Salesforce app to support your national nonprofit network, chapter organization, collaborative or other sector-wide initiative, keep reading! The case for a replicable Salesforce solution is compelling and the potential for scaling meaningful change in our communities is awesome.

Although I didn’t start out as an app developer, over the years, I’ve learned a lot about what it takes to develop and distribute a Salesforce app. I’ve worked with some great partners including Nineta Martinov (DaizyLogik), Brian Pickett (North Peak), Rem Hoffman, (Exponent Partners), Sara Chieco (now at Presence Product Group), Brad Struss (Bigger Boat Consulting), Kevin Bromer and Laura Meerkatz (both now at Salesforce.org), who had great advice. Use these questions to help plan and assess your readiness and capacity for taking on a long-term technology project.

1. What are you hoping to accomplish?

Clearly articulate why your organization wants to be in the business of creating technology solutions for other nonprofits. Review this list with your team and stakeholders and prioritize your goals given your mission, vision and capacity.

• Member Services: Support your membership or related affiliates by responding to their needs for new and/or improved technology solutions
• Capacity Building: Build capacity in your sector by helping nonprofits leverage technology to reduce inefficiencies and scale their impact by standardizing best practices
• Data Collection: Facilitate sector research by providing an easy way for programs to collect standard data in a systematic way
• Outcomes Tracking: Measure impact at the program and sector-level in a way that was never before possible without a formal research study
• Technical Innovation: Replace an aging legacy systems within a sector niche
• Economies of Scale: Provide a technology solution that is not currently met in the market, but is larger than any one program could take on themselves
• Streamline Reporting: Simplify your process for member or grantee reporting for similar programs
• Community Building: Strengthen professional connections and networks between individuals in your sector, network or membership
• Market Opportunity: Build a sustainable business enterprise to generate revenue for your organization (Note: This should never be one of your top 3 goals. See #3 below for details)

2. Who are you building this for?

It’s difficult to build a solution from the start that meets the needs of multiple audiences, each with their own priorities. So take a moment and ask your team, “Who are we primarily building this for?” Think through their biggest pain points. What systems are they currently using, and how’s it working for them?

• Clients of programs, organizations, and agencies who maybe not be getting the best service due to out-of-date case management procedures
• Front-line staff who are drowning in paper files and spreadsheets or may want to coordinate with other program partners in the area
• Program directors who keep asking front-line staff for a lot of reports and data points
• Your colleagues, including member engagement directors or grant managers who need to aggregate data from the field
• Think tanks and researchers who want to access large data sets
• Policymakers who need to see real data on your sector, intervention, or program model

3. Do you have patient funders and a sustainable financial model?

Harnessing a “Market Opportunity” should not be one of your top goals because it’s unlikely you’ll be able to recoup your initial investment and all of your operating subsidies. Let’s assume you’ll need some startup funds for your initial product planning, initial build out, and testing phase. And you probably won’t earn enough revenue to cover all of your costs (primarily staffing, development consulting fees, and overhead) for the first year. Or two. Or three.

So what’s your plan to cover one-time and ongoing expenses in the meantime? If your project is primarily about collecting social impact data, consider the various business models that might support your efforts. Estimate how many users you will you need to become self-sustaining, and assume the product development, sales and on-boarding process will take longer than you think. In fact, assume everything will take longer than you think, including achieving financial sustainability.

Are your funders patient and flexible and do they understand your short-term needs and long-term vision? Do you have a supporting executive team and board leadership, that can help with fund development and sustainability planning?

4. What is or will be your relationship with participating organizations that will use your solution?

Early on, it helps to establish relationships and set clear expectations with a core group of organizations planning on using your product. Ideally, you or someone on your team has actually worked in the role of the prototypical user. If that’s not the case, this group of core advisors are even more essential. They will help provide guidance, input, and feedback which is particularly valuable in the early phases of development. Think through these questions to better define your roles and relationships.

• What is your role and relationship to potential users and what makes your organization uniquely qualified to scale a technology solution?
• Will you lead a collective effort to develop a solution together or on their behalf? Or, will you drive the development process, periodically soliciting their input and feedback as needed? Or, will you defer to a third-party development party to take the lead?
• Will you start with a core pilot group, and what will they get for being the guinea pigs?
• Will there be formal agreements, such as participation agreements or non-disclosure agreements?
• What are your estimates for the time and effort needed to be a part of the core group and how long will the engagement last?
• Will you be compensating subject matter experts to share their knowledge, will they be paying you to participate in a pilot program, or will there be a mutual no-cost agreement?
• Will organizations be paying you for the solution, or will you be covering the onboarding costs and their expenses with grants?

5. How will you distribute your solution?

Knowing how you are going to share your solution with others is one of the most critical and early decisions you’ll need to make. There are two common ways of distributing your solution: a Salesforce managed package, or a single org instance. Which one should you choose? It depends. If neither is a perfect fit, look for other opportunities to layer in products such as Salesforce Community Cloud or see if any other third-party solutions can help you meet your goals.

An app, or “managed package” in Salesforce-speak, is what I call a “one-for-each” setup. Each participating organization gets their own Salesforce account, or “instance”, and installs your app. Each organization has control over their own account, and has the flexibility to add features, additional customizations, or other apps. The app is upgradeable, so you can push out new versions and features to users, but the data for each organization is stored separately.

The other option is what I call the “all-in-one” setup. You build one custom solution in your one account, and your participating organizations login to submit, enter and/or manage their data. While the initial setup may be easier than developing a managed package, organizations are not easily able to connect this data to their own instance or data systems because data from all the participating organizations is stored in one place.

Note: Salesforce also has an Unmanaged Package feature, but this route may not be advisable if you are planning on scaling a technical solution to multiple non-profits and making updates over time. Features are not upgradeable in this scenario, and any changes to the base application must be made individually to all the users manually.

6. Will you be aggregating data from your users?

If you are collecting standard reports or datasets from participating organizations, you’ll also need to include additional controls and features into your app to ensure records are complete, correct, and consistently entered in accordance with your data standards.

If your users are using your managed package app, they will be managing their data in their own instance or system and you’ll need to build an integration to centralize the data. For example, in addition to building our HomeKeeper App, we also built the HomeKeeper National Data Hub to aggregate the data from our users, and an integration process using middleware technology – to pull data from the participating organizations and push it into our Hub. If your organizations are logging into a single system, data aggregation is much simpler.

• How frequently will you collect data?
• Will you collect detailed data from individual records, or information from a summary report?
• How will you audit the data for completeness and correctness?
• Will users need to do anything to submit the data to you, or will it be aggregated automatically?

7. Are you reporting on impact and metrics across multiple programs?

If the answer is yes, then estimate your potential workload, budget and timeline to build your solution, and then double it. Or to be safe, triple it.

While sector-wide reporting may seem to be the same project as building a shared measurement or data collection system, or aggregating data from users, cross-site reporting requires another layer of complexity. You will have the additional task of analyzing the data you’ve aggregated, developing meaningful metrics, and building a way to share publicly accessible reports and dashboards.

• Who is the primary audience for your collective reporting and how will you present and share your data?
• Will your reports or dashboards be accessible and available to the public online?
• Will your online dashboards be interactive, with filters available to help users slice and dice the data?
• Who can access the source data, and under what circumstances?

If you decide to add the additional feature of peer-benchmarking, your participating organizations can compare their outcomes to their peers. This can provide valuable insight, but will make your project even more complex.

8. How will you staff and support your app?

Building an app takes one set of expertise, but supporting your app creates additional ongoing staffing demands. Do you have a product owner who can set the vision for the product or program, prioritize new features, and manage the overall team of advisors, developers and consultants? Is it someone who comes from the field or understands the challenges of end users, and has some sector knowledge? You will likely need additional staff to fulfill key roles:

• Managing a pilot, including onboarding, training and gathering feedback
• Overseeing development (and or developing the product)
• Marketing and sales to spread the word and invite people to a demo call
• Onboarding new users and providing ongoing product support
• Developing technical documentation and user documentation, and coordinating trainings and office hours
  Accounting and administrative support

9. What is the ownership model and governance structure?

Assuming your organization has ownership over the product development process, who will own your solution? Will you create a new business or nonprofit entity, or will it be a program, a product, or an initiative of your existing nonprofit?

• What rights, if any, will your developer and other consultants have to the products you develop?
• Who gets to make decisions, and to what extent do participating organizations get to influence your project and your roadmap?
• What role will your organization play, and how do the goals of this project fit within your larger mission?
• Will you have an advisory committee of sector stakeholders and what will their role be?

10. Who will be on your team?

Regardless of what approach, you’re going to need a team of experts to help you navigate through the process of developing and sharing a technical solution. Here’s a short list of some of the folks you’ll want on your team. If you don’t already have these skillsets in your organization, don’t forget to budget for these third-party contracts.

• Subject matter experts, including potential users, their supervisors, and key industry stakeholders
• Salesforce consultants and other partners or technical advisors, including a product development outsourcer (PDO) and/or developers specializing in product development and shared solutions
• A business consultant to help model expense and revenue forecasts, assess product value, and advise on insurance needs, market segmentation, market sizing, developing and managing a sales process, and pricing models
• Marketing consultant to help with a public launch, producing a web page, logo and branding guidelines
• Research consultants, including experts who can advise on metrics, data points and field definitions
• Legal advisor to assist with user agreements, trademarks, contracts, non-disclosure agreements, data sharing agreements and intellectual property rights. You may also need legal support to setup your business structure or advise on how your activities affect your non-profit tax status

Find your path forward.

Being an accidental admin is one thing. But becoming an accidental app developer comes with a whole new level of risk and responsibility. Developing a technology product and supporting program for multiple organizations will require a strong lead organization and a long-term commitment.

Hopefully these questions have helped you assess your organizational capacity, your project budget, and your team’s skill sets. Doing some early discovery now before you get too invested in the project will help you better plan your staffing needs, set appropriate expectations, and build better consensus around the definition of success for your project.

Salesforce for Nonprofits – Resources

You are not alone. There’s a wonderful community of nonprofit Salesforce folks in the Power of Us Hub, a Trailhead module on Salesforce Basics for Nonprofits, and there’s even a group for “Collaborative CRMs” which brings together individuals pursuing similar large-scale initiatives. Learn from our HomeKeeper story and others, like College Forward, TaroWorks, and Hands on Connect, that have already blazed this trail. Find a mentor and talk to peers with similar projects that can help light the way with guidance and inspiration

There is no one right way to proceed with building your sector-wide solution. But by asking the right questions and learning from others, you will be well prepared for the journey ahead.

About the Author
Tiffany Eng is a Program Director of HomeKeeper at Grounded Solutions Network. She oversees product development, marketing and outreach

Starting with a degree in city planning, Tiffany began her nonprofit tech career as a part-time consultant to help with a data project for the affordable housing sector. What began as a small consulting project expanded to become HomeKeeper, a Salesforce web application designed to help over 65 affordable housing and housing counseling programs better manage information and measure impact. The HomeKeeper program now spans a large data ecosystem including two managed packages, middleware, the HomeKeeper National Data Hub (a data warehouse), public interactive dashboards, and peer benchmarking reports. Additionally, HomeKeeper twice received the Salesforce.Org Force for Change award which helped their early success.