Before getting started building anything new (not just integrations), it's important to take the time to think about what you are trying to do exactly, and why you are trying to do it. This is especially true when it comes to integrations, because they can be a significant investment of time and resources (at the expense of building other core product features).
Do you need integrations at all?
I know it sounds silly coming from us, but this is really the place you should start. It's easy to get caught up in the excitement of integrating with other systems, but it's important to remember that integrations are a two-way street. They require maintenance, and they can be a source of bugs and security vulnerabilities.
Integrations are not a substitute for product-market-fit
If you're a small company, you might not need integrations at all. You are almost certainly better off focusing on your core product and building a strong customer base before you start integrating with other systems. I know it can be tempting to jump to integrations because:
- You're not sure what to build next
- Some potential customers may be asking for them
- You think it will help you overcome sales objections
All of these points may be true. But remember, if your product solves a really painful problem for teachers, students, parents, or admins, they will use it even if it doesn't integrate with their other systems. To put it another way: people aren't going to adopt a useless product just because it integrates with Google.
When integrations make sense for your company
If you're a larger company, or if you're a smaller company that has already found product-market fit, integrations can be a great way to:
- Make sure your schools are getting the greatest possible value of your product
- Make it easier for customers to use your product
- Make it easier for customers to switch to your product
- Run pilots with potential customers
- Increase your sales velocity by dealing with common objections
- Improve your employee to customer ratio by automating things that used to be done manually
What integrations do you need?
The three general types of platforms that Edlink integrates with are LMS, SIS, and identity providers (such as Clever and Classlink). Companies that work with Edlink will often support multiple types of integrations, but it's important to think about which ones are most important to you. It's also worth thinking about how to handle differences between the systems (e.g. which systems support grade passback and which ones do not).
Why you might want to build LMS integrations
- Your product is used in classrooms or at home by students and teachers
- Your product is used to create, assign, and grade coursework
- Your product is used to track student progress
- Your data requirements (e.g. demographics) are not super complex
Why you might want to build SIS integrations
- Your product is used by admins to manage or analyze student data
- You have complex data requirements or rely on better organized data
- Your product contains summative assessment data that needs to be reported to the state or on report cards
Why you might want to build identity provider integrations
- Your product only requires SSO and rostering
- You work with a lot of schools or districts in the US K-12 space
How cleanly does your data model map onto external systems?
Answering this question will help you understand how much work will be involved in building the integration and how deep the integration can be. If your data model is very different from other external systems, it may require a lot of work just to get your product to the point where it can interface with another system.
Another factor here is how "common" your data is. If your data model is very unique, it is unlikely that other systems will even be able to represent it in a structured way. This is not necessarily a bad thing, but it may limit the depth of your integration. For example, if you're building an application that helps districts track daily student behavior, then it is unlikely that you'll build an integration that goes beyond SSO and rostering. In this case, the data itself is what makes your product unique and other systems are unlikely to be able to store and represent it.
Other important questions to consider
- Is there a migration process involved for existing customers?
- What do you do if a customer wants to switch from one system to another?
- How will you support these integrations as you grow?
- How will data transfer or persist across school years?
- Is your data meant to persist across school years or can it be archived?
- Will students and teachers all have "fresh" accounts each year?