Developing a Platform on a Shoestring Budget
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
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:
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:
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.
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. Manyof 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.
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!
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!
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:
After many website relaunches with ZNotes, I’ve realised that in fact, the moment you actually go live and the time you post it across social media don’t actually have to be exactly the same. They don’t even have to be the same day! With this launch, knowing that there were a whole bunch of things which could go wrong, we decided to quietly switch the website in the evening before launch day, when the website traffic was a bit low. I’m sure we surprise the 15 people who were on the website at the time.
The moment you go live, make sure you are vigilant and that your developers are around on call. In the words of Mad-Eye Moody:
Even with all the precautions we took, we ran into some major issues the next day. Although everything was fine on beta tests, when we went live and had almost 50 concurrent users, our poor servers couldn’t handle the pressure. This led to error messages being sent out for users on our website. We beefed up our servers and things got a bit better.
The Future
Breathe. Pat yourself on the back. Because all that effort was worth it – you’ve produced something that is being used by people all over the world.
But this is just the first step. Your platform must continue to evolve and improve the end user’s experience. And for this to happen, you must continuously gather feedback and develop new features.
I always think of ZNotes as an organism rather than a website or a platform. Like me, it has grown and matured. It can perform new tricks and serve even more people. Having launched 3 weeks ago, we’ve had over 100k page views and almost 10k registered users. We’ve had both positive and negative responses for our new platform and there is much to improve. But we have loads of cool ideas to work on.
We’re only just getting started 😉
