When is it worth building a proof of concept?
It doesn't always make sense to build a proof of concept when evaluating Edlink. In this section, we'll discuss some of the factors that can help you decide on the best course of action.
Reasons why you may want to build a proof of concept
- You're planning out a brand new aspect of your product and want to see how Edlink can help you achieve your goals.
- You want to be able to produce some basic user experience flows to show to stakeholders.
- You want to get a more accurate sense of how long it will take to integrate Edlink into your product.
Situations where it's probably not worth building a proof of concept
- You've already built one or more integrations with external systems.
- You're not building out an entirely new piece of functionality for your product.
- You're already familiar with Edlink and how it works.
- You're confident that Edlink can meet your needs based on the documentation and sandboxes available.
How much time should you spend?
This is a tough question, but in general, we recommend not spending more than 2 developer weeks on a proof of concept (i.e. 1 developer * 1 sprint). This should give you enough time to get a good sense of how Edlink will work with your product and how the user experience will feel to your end users.
Alternative approaches to building a proof of concept
A great alternative to building a proof of concept is to use a prototyping tool like Figma or Sketch to create a high-fidelity mockup of your product with Edlink integrated. This can give you a sense of how the user experience will work without having to write any code. It will allow you to rapidly iterate on your plans and get feedback from stakeholders before you start building.
Our engineering team is also happy to provide feedback on your mockups and help you refine your plans before you start building.
How should you define success for your proof of concept?
We recommend that you pick a few key metrics to measure the success of your proof of concept. Here are some examples:
- Can we successfully authenticate a user via Canvas?
- Do we receive the roster data that we are expecting and are there any fields that are important to us that are missing?
- Can we successfully create an assignment in our product and see it reflected in Google Classroom?
In summary:
- Be specific in your choice of objectives.
- Select objectives that are mainstream use-cases for your product.
- Choose a specific timeframe for your proof of concept.
There will undoubtedly be things (both edge cases and major cases) that you are not thinking about right now. That's okay! The goal of the proof of concept is to identify at least some of these unknowns and address them before you start rolling a solution out to customers.
How to get started
- Sign up for a developer account on the Edlink website.
- Request access to one (max two) sandbox sources that you're interested in integrating with. We highly recommend that you pick the most important sandbox source (e.g. Google Classroom) for your product. Picking a
- If you're looking to build SSO integration via Edlink, please reach out to our team so we can provide you with sample teacher & student accounts for testing.