eLearning Software Development: LTI, SCORM, xAPI or Your Own Format?

In eLearning software development, the choice depends on who signs your contracts. If you sell to schools, universities or corporate training teams, build on standards: LTI to plug into their LMS, and SCORM or xAPI for the content. If you sell straight to learners and run the whole experience yourself, your own content format is faster and gives you more control, as long as you plan a way to export it early.

Maybe you have a working prototype, a pilot with one college, and a procurement form asking "Is your tool LTI 1.3 compliant?" Or maybe you're building a consumer app and wondering whether anyone will ever ask. Both are normal places to be. They just lead to different builds.

What do LTI, SCORM and xAPI actually do?

They solve three different problems, which is why founders often mix them up. LTI connects your app to an LMS. SCORM and xAPI describe how learning content reports what the learner did.

LTI 1.3 (with the LTI Advantage services) lets a teacher add your tool inside Canvas, Moodle, Blackboard or Brightspace. Students click a link and land in your product already signed in. Grades go back to the LMS gradebook through the Assignment and Grade Services API. Class lists can come through Names and Role Provisioning Services, so nobody has to upload a CSV.

SCORM (1.2 and 2004) is a zip package with a manifest file and a JavaScript API. It runs in a browser window inside the LMS and reports completion, score, time spent and where the learner stopped. It is old and limited, and it is still everywhere in corporate training.

xAPI records learning as statements, such as "Priya answered question 7 incorrectly", and sends them to a Learning Record Store. It works on mobile, offline and outside the LMS. cmi5 is a set of xAPI rules for launching content from an LMS, so it can do the job SCORM used to do.

A proprietary format is whatever your own database and player understand. Lessons, quizzes and progress are shaped around your product, not around a spec written for everyone.

How do standards change institutional sales?

For institutional buyers, LTI is often a requirement before they will even consider you. An IT team approving a new tool wants it inside the LMS they already run, with single sign-on and grades sent back automatically. That means no new logins for students and no typing grades in by hand for staff.

Without it, your champion has to explain to IT why students need yet another account. That champion is usually a teacher or learning lead who loves your product. Many deals stall right there, in the security and integration review, not in the demo.

Corporate L&D teams ask a slightly different question: "Can we load this into our LMS and track completions?" That usually means SCORM or xAPI packages, because their compliance reports run on that data.

What happens to portability and analytics?

Standards make content portable, but they also limit what you can measure. Your own format works the other way round.

SCORM tells you roughly four things: did they finish, what did they score, how long did it take and where did they stop. Your product's value might be insight, like which concept a student keeps getting wrong or how long they hesitate before answering. SCORM data will not show any of that.

xAPI can capture much richer events, but only the ones you design. You need a plan for verbs (the actions you record) and activity IDs (the names you give your content). Without one, the Learning Record Store fills up with mismatched statements nobody can search.

A proprietary format captures anything you choose, in as much detail as you want, in a shape your analytics can use directly. The trade-off is that the content only exists inside your product. If a customer wants to leave with their courses, or run them somewhere else, you need an export that you have built and tested.

What does it cost to get this wrong?

The usual mistake isn't choosing the wrong standard. It's choosing none and then adding one in a rush when a deal depends on it.

When a large district or university finally asks for LTI, teams often find three problems. Their user model assumes one login per person. Their roles don't map to "Instructor" and "Learner". Grades sit in a table the LMS can't reach. Fixing that means changing authentication, permissions, data models and how you separate customers' data, all at the same time. It can take weeks of rework while the deal waits.

The opposite mistake hurts too. Teams that force every lesson into SCORM to look ready for enterprise end up with a clunky player, thin analytics and a product that feels like every other course tool.

Either way, you lose momentum with the buyers you actually have.

When is your own format the better choice?

If you sell to individual learners or parents, create your own content and never expect to sit inside a school's LMS, you don't need LTI or SCORM yet. Language apps, test-prep apps and creator course platforms usually fit here.

Build your own format, keep it clean, and put the time you save into the learning experience. Just keep three things in place: a permanent ID for every lesson and learner, a log of what learners do, and a content structure you could export later.

A decision path you can follow

• If your buyer is a school, college or university, include LTI 1.3 with grade passback in your first architecture review, even if it ships third.

• If your buyer is a corporate training team, support SCORM import or export for their compliance reports. Look at xAPI or cmi5 if they also track learning outside the LMS.

• If analytics is what makes you different, use your own event model inside the product and translate it into xAPI on the way out. Don't let a standard decide what you measure.

• If you sell directly to learners, use your own format now and plan how you would export it, without building the export yet.

• If you're unsure, ask your last five serious prospects what their IT or L&D team required. Their answers will settle it faster than any spec sheet.

Many teams end up with a mix, and that's a sensible setup: your own detailed format inside the product, LTI where it meets institutions, and xAPI statements sent from your event log.

What should you ask an eLearning software development partner?

Ask these before anyone writes code:

1. Have you shipped an LTI 1.3 tool, and which LMS platforms did you test it on? Each one behaves a little differently.

2. How will LMS users map to our accounts, roles and customer accounts? This is where most late additions break.

3. Which xAPI verbs and activity IDs will we use, and who maintains that list?

4. How will we test SCORM packages, and with which tools?

5. If a customer leaves, what exactly can they take with them?

Be wary of a vague answer to the second question. That's the part that turns into a rewrite later.

Your next step

Write down who will sign your contracts in the next twelve months, then pick the standard that buyer needs, not the one with the longest feature list. If your platform already exists and the LMS question is forcing bigger changes, this guide to rewriting an EdTech platform explains how to decide between refactoring and rebuilding.

Or send Geminate Solutions your current architecture or plan for a free review. We sign an NDA before we talk and reply within 24 hours.