How to build your own web application using ClickFix and Ontraport

Step 0 : Introduction

What you are about to learn

Dear reader,

This page has one goal : by the time you are done, I want you to feel confident building a web application using Ontraport and ClickFix.

By 'Web Application' I mean any system that let's your users/clients act upon or interact with your business beyond giving you their email address.

A self service support system is a web application. An event booking system is a web application. A multi step onboarding process is a web application. A learning management system also is an application.

For decades now, building a web application has required an expensive skillset (front end developer, back end developer...) and a long development cycle.

But if you break the process down, a web application is nothing more than :

a place to store data (database)
plus an interface to view and act upon that data (front end)
plus a way to act upon that data automatically (back end)

Today, thanks to Ontraport we can now store that data, act on it with campaigns and build an interface in Ontraport pages to act upon that data.

All that was missing was a way to make Ontraport Pages dynamic so one could build a proper interface with it, and a way to easily access the Ontraport Database from that page.

It has been our effort the last three years to make this process very easy, and ClickFix is the bridge between the three corners of the development triangle that'll allow you to use Ontraport as a proper low code application development platform.

Warning : The limitations of this technology

I would be doing you a disservice here if I wasn't mentioning the built-in limitations of combining ClickFix and Ontraport to build web applications.

One of the main limitation is the Ontraport API's speed and call limit.

(We will, by the end of october, solve this for content that doesn't evolve much on a given day by providing you with Caching features, so we only need to call the Ontraport API once and we can then deliver that data instantly to millions of visitors without an issue.)

Some reasons NOT to use Ontraport+ClickFix and instead hire a development team :

you need native mobile applications (something they can install on their device) and you don't want your users to boot up their mobile browser
speed and instant information are very important to your application. For example if you are building a linkedin-like application for your users to network on and you need them to message each other (instant information), this won't work very well
you expect to manipulate / display a LOT of information. For example, an event platform with 100s of events accommodating 1000 guests, and those guests managing 100s of their own tickets is totally fine. But if you are filling up stadiums of 50.000 people on a weekly basis and you need your staff to see and search that whole list, then this is probably not the right technology for you.

To give you an idea as to why : it would take a good 10 minutes to generate that 50.000 list so your staff can use it, due to Ontraport's API limitations. And we need to re-generate that list every time a ticket is updated (created, checked in...).

For a 1000 guests event, the list takes under a minute to generate so the issue is non existent.

Feel free to contact us if you are unsure if you are making the right choice, it's in everybody's best interest and trust me we are looking for lifelong clients here :)

Exemple Use Cases

You can find examples of web application on this site : https://demo.clickfix.io

We are currently making explanation videos for each case study, stay tuned!

Step 1 : Thinking the project through

The first step in your web application project should not be to think of Objects, Fields or Systems. Not one bit.

The first step should always be for you to imagine what the USER EXPERIENCE will be like. Let me explain with an example.

A lead came to me not long ago wanting to build a complex event system for a dress shop. Complex because 'events' in his case can mean managing your wedding online, or booking a visit to take your measurements, or bringing a few bridesmaid around for a dress rehearsal.

Now that is not a small project, and it'll end up being made up of 12s of forms and pages plus probably close to 100 campaign triggers. It can be overwhelming if you're trying to plan every single choice and system in advance.

Instead, I advise you stay agile and DON'T plan in advance too much. Your should be aware of potential pitfalls so you don't corner yourself into an unsolvable issue/situation, but you do not need to know everything that will be built before you dive in.

Instead, you need to know at this point very clearly :

WHO will be using this, who are the stakeholders
WHAT they will be using this for, what are the end goals/features we want to provide
HOW that will look in real life (what buttons will be clicked where)

Let's go over each step.

WHO will be using this

Systems are made for humans, not the other way around.

When starting your project you should always start by thinking about WHO will be involved.

Generally we have three stakeholders :

The Boss, who owns the business
The Staff, who runs the business
The Client, who interacts with the business

Some projects have a lot more stakeholders :

the Client may himself want to bring HIS Staff in
the Boss may have Shareholders he wants to show reporting to
the Staff may be made of Coaches who deliver something to Clients and of Support Reps who help Clients in all sorts of ways
the Legal Department may have some things to say regarding this application and the law
etc...

Each of those Stakeholder will have different needs that need to be met, different expectations and requirements about what the application you are building needs to do for them to be happy using it. Which leads us to...

WHAT will they be using it for

Now that you have your Stakeholder list, it's time to provide as much value as possible to each of them. This is the 20.000 feet view of the project.

Even if we will NOT map all systems in advance, this part needs to be exhaustive. Dream up, think away, brainstorm the heck out of this part, but make sure there is everything you can think of there. This will be your Dream Product. What you may or may not end up with a few months from now.

An example for a simple event system could look like this :

BOSS features

ability to view past events
ability to view future events
ability to view attendees list from a specific event
- ability to check them in
- ability to uncheck them if a mistake is made
ability to view event data
- tickets left to sell
- tickets sold
- attendance
ability to add new events to be publicly sold, an event being defined by
- location
- date & time
- number of available seats
- ticket cost

STAFF features

ability to view current (today) event
ability to view attendees list
- ability to search a specific attendee
  - first name, last name, email, phone number should be searchable
- ability to check them in
- ability to uncheck them if a mistake is made

CLIENT features

ability to view upcoming tickets
ability to view past tickets
ability to print an upcoming ticket
ability to book into a future event without entering credit card information

Easy right? Now all that's left to do in this first step is to move on to the HOW.

HOW will they use it

HOW doesn't relate here to HOW DOES IT WORK.

HOW in our context means : How will each stakeholder be interacting with each of our feature?

What do we need to give them so they can do the things, the WHAT, described above?

Again, don't even think about Custom Objects or even Ontraport at this point.

Instead what you need is to figure out...

...the UX, or User eXperience!

What will my app look like? What pages do I need? What forms to do what actions? What data do I need to display and where? What button will be clicked and where will it take them?

I personally like to do this exercise on paper, but there are many applications out there that will let you do it online. Or you can even just go into Ontraport Pages and start there!

(just forget about form fields at this point and write down "here goes a form to add an event").

You can see the end result for the event system above here :

(everything is clickable so you have an idea of navigation, BUT nothing is functional)

Step 2 : Objects, Fields and Relationships

Although requiring a bit of a more technical background (but we can help with this part very easily if you can go through Step 1 on your own), it is now time to actually think "Ontraport".

Ontraport Custom Objects 101

Some of the following will sound like heresy to any developer reading this, so forgive me in advance :)

Also if you already understand Custom Objects and the Relationships between them, you can skip this part.

When you first log into your Ontraport Account, you can see a few 'tabs' there, two of which are :

contact
sales/purchase

Those are both "Objects" in their own right. Ontraport gives you the right to create as many objects as you want in exactly the same fashion. Each Object will have its own messages, fields, campaigns...

A new object could be for example an Event, a Pet, a Car...it is really based on what your business is about.

A CONTACT may do many PURCHASES.

But a PURCHASE can only be made by ONE CONTACT.

This is what we call Relationships : a way to link together different objects. You can read more about this here under "Understanding Custom Object Relationships" :

https://ontraport.com/support/crm/custom-objects-overview/

Without going into too much details, let's run through a few scenarios so you can find out if you are going for a One To Many (1-M) Relationship or a 1-1 Relationship.

(I very rarely use Many to Many (M-M) relationship because a M-M is actually two 1-M tied together, you'll understand why below)

A Team Management System

A Client of yours needs to add Staff members to a portal you manage, and only he can do that.

Clients are CONTACTS

Staff are CONTACTS

There are two ways to do this actually.

Via a COMPANY Object
1. COMPANY 1-1 Client
  
  (only one boss of this company)
2. COMPANY 1-M Staff
  
  (only one company has multiple Staff People)
Directly through the Boss/Client
1. Client 1-M Staff
  
  (only one Client or Boss has multiple Staff People)

A Contract Portal

You need your Clients to sign Contracts/Agreements on a regular basis.

Clients are CONTACTS

Agreements are a new CONTRACT object

Clients 1-M Agreements

One CLIENT can be tied to many CONTRACTS.

If you are after "One Document signed by X Clients" then things get more complex.

In theory it is a Many to Many Relationship, because one CONTRACT can be signed by multiple CONTACTS. But we don't like many to many relationships so instead we'll create a third object called SIGNATURES.

A CLIENT can have Many SIGNATURES, and a CONTRACT can have Many SIGNATURES.

And so it is
CLIENT 1-M SIGNATURES
CONTRACT 1-M SIGNATURES

And so a SIGNATURE is the meeting between one CONTACT and one CONTRACT.