Developing a Platform on a Shoestring Budget
By: Zubair Junjunia
Tags: Development, Entrepreneurship, Startup, Education, Technology

It. Was. Hard.

To quote Hamilton, I had “to beg, steal, borrow, or barter” to bring my vision to reality. And I made many, many mistakes along the way. So if you are setting off or have just started the journey of trying to build some kind of platform or website, here are a few things I learnt the hard way and I’d like to share.

What can you do yourself?

Whether you consider yourself a programmer or not, there is a whole lot of stuff you can and need to do for this to be a successful endeavour. Before you even get started, indulge me by considering these fundamental questions:

Who is your end-user? What are they trying to achieve? Which of the pain point in the current systems are you trying to alleviate?

If you can come up with a succinct response to each one, you’re ready to keep moving forward. Programming is a daunting task but when you take off all its fancy bells and whistles, it is nothing but the ability to build certain procedures following a logical route. And as with any skill, it is shrouded away in jargon to further confuse a newbie. Don’t be scared! I was lucky enough to have learnt some Python (and a couple of other languages) during school and university but I don’t possess any of the skills that it takes to develop all these awesome apps that are out there.

To get started, you need to work out the ins and outs of what your app or website is trying to achieve and this is done by creating a Systems Requirement Specification. Ha, the jargon is already getting in! This simply means a document outlining the basic requirements of what your software should do so a developer can better understand and refer to it. There is no fixed rule of what it needs to have but a few basic items that I think you should (and we did) include are the following.

The Purpose

The purpose follows from the three fundamental questions we looked at in the start. In the simplest words, tell me what your software is trying to achieve. And why is it worth building?

Use Cases

Probably my least favourite but most important part of it. You essentially need to explain the journey of someone on your website or platform as though to a six-year-old. Write a list and number each part of the process. If at some point your user has multiple things that they can do, break the process down a further level. And well done! You’ve also just learnt about the IF ... ELSE procedure of a program. It is crucial that you untangle all the paths the user can take and think of the most fundamental ones. Remember, once this is all built, your user can go do many things, even simultaneously! As an example, check out how we imagined the process for a user on the ZNotes platform to enrol on a course

Ignore the ‘API’ — it’s not an important point

Data collections

This may or not be applicable to you but if you are storing some kind of information, whether it’s user information or bits of media that will be coming on to your platform, you need to say how and where these pieces of information will be stored. It’s essentially explicitly describing each piece of information and what ‘collection’ it will be stored with. Here’s an example of what a user on our platform was imagined to consist of:

It doesn’t have to look like the Matrix! Simply use a few bullet points.

Designing and Visualizing

It’s magnificent, isn’t it? The way it looks like in your head. Unfortunately, that is also the tragic flaw of this beautiful image. It resides solely in your imagination and we haven’t yet developed the technology to hook your brain to a machine and download that picture. So for now, it is your job to sketch the design.

As before, you don’t need to be an artist or a professional UX designer to get started. My favourite tool for prototyping (and this is what I still use every day!) is Microsoft PowerPoint. Crazy, right? The thing I love about it is how quick and easy it is. Use a bunch of shapes and mess around with the fonts and text-boxes. Et voila! You have a simple homepage to get started with. Another cool thing is that you can have multiple slides to illustrate the user’s journey. Design each screen independently and then in slideshow mode, flicking through them is an awesome way to visualise how a user will navigate through. Here are some of the first few designs I started on PowerPoint:

I know — it’s awful!

These prototyping exercises are crucial because unless you do them, you can spend a whole lot of time developing something which is unusable. Once you have some sketches and possibly a slideshow for your user to walk through — test it! And this can be done with anyone. Actually, it is most useful if it is someone who is a complete outsider to the project. They can provide the most critical feedback as they have no previous knowledge.

When we are too close to the project, we have, what I like to call, ‘the curse of the knowledge’. We can make unprecedented assumptions on the understanding and interaction of the behaviour. A good rule of thumb is to design for the device with the least specs and the most incompetent user — if it works for them, it’ll work for all!

Although you can get quite far along on your own, it really does help to bring a professional designer on board at some stage. They’ve been trained to understand how different typography, colours and placement can make the best user journey. Having created some drafts on PowerPoint, we brought a UX student to help reiterate and produce them on Sketch. After this, we got insights from other people and designers for critical feedback. Here’s what we came up with.

This was all designed in a software called Sketch

Remember, the designs can look absolutely stunning but these also need to be programmed into reality. Usability and functionality should be the key drivers of your design. A good aesthetic is a by-product of this.

The Development

The longest and most difficult stage. And the place where things go wrong most often. As we didn’t have the talent on the team to actually develop the platform ourselves, we had to outsource the work. We definitely faced our biggest challenges here, including having three different sets of development teams get involved and a launch that was months from when we planned it. Here are some things I wish I knew when I started.

Imagine the worst that can happen. Then double it. Unfortunately, development means finding more and more holes in your concept… … which leads to extended timelines … … and higher costs.

Now I don’t want to be completely negative. Many of the challenges could have been mitigated by being more careful in our planning. But unexpected things happen so be prepared.

If you are planning to outsource your development work, make sure you have good chemistry with the team you hire. Spend time and speak to them — make them excited about the solution you are building together. Without a collective belief in the solution and a strong work ethic, it becomes much harder for the work to be done.

Management and Monitoring

Which leads us to the management. Once you’ve identified that team who will turn your dream into a reality, you need to find a place and way to work together. Most developers will choose to work through GitHub, a place that allows you to easily manage many different people working on the same code base. Recently, GitHub has also given the ability to create a private repository (a place where the code will ‘live’) which means that all your intellectual property will also be safe from prying eyes.

Our code resides inside the ‘znotes2’ repository

It is also important to monitor which tasks are being worked on. The best solution we found was to use Trello. With its Kanban structure, it makes it very easy to set tasks and bring them from planning to deployment stage using the cards. Look at how many tasks and cards we had in the end!

And yes, there is still a lot to scroll within each column!

Usually, at the start of the week, I would speak to my lead developer and plan out the tasks that we plan to achieve in that week. This is based on the Google Design Sprint system, which takes a feature from conception to reality in 5 days. We plan and clearly define each piece of work, estimate how long it will take and set up a card for each, often assigning the specific developer who will be handling it (possible to do through Trello). During the week, you can monitor the work your team is doing by checking Trello and the stage of each task as well as the deployments which have been made on GitHub.

The Testing Time

So you think you're done? You might have to put a few of those killer features on the back burner and simplified that cool design. But now you have a real-life, functioning platform. Congratulations! The next step is to make sure that everything is working as it should. And the best way is to bring a whole bunch of people to try it out and give you feedback.

Depending on how complicated your platform is and whether it has an existing form, this can take different amounts of time. When we had a reasonably functioning platform, we brought on some of our community members for the beta testing and gathered feedback and bugs. This tends to lead another couple of sprints for bug fixes. Sorry, you weren’t quite done yet!

The channel for beta feedback on the ZNotes Discord server

We also had the mammoth task of turning hundreds of our resources into the form that would work with our new platform. So overall, our beta testing time lasted over a month but at this time, we attacked and plugged all the leaks on our ship.

Going Live

*drum roll*

The big day has arrived! Everything is in its best possible form at this stage and you’ve made sure with all your beta testers that things are working. It is time to invite the whole world to try it! Hopefully, you’ve made a bit of a buzz on social media and got some people’s email, inviting them to be your first users! These were the first promotional pictures we released: