Around 2014 polish government decided that there is too much junk food in schools, so their voted to ban selling it in small shops inside school buildings. As the idea was nobile and right, the result was that most of those shop had to close their business, since they lived from selling donuts rather than apples. The final outcome was they could not buy any food inside school at all.
Tuszama is an web and mobile app that meets the needs of those hungry students — it allows pupils in high schools to order food at their grand break. Whole process of ordering is straight forward — all you need is to:
- Create an account
- Select your city
- Select your school
- Order available food
- Collect food on grand break between lessons.
There are few rules in the application
- Client — student that orders food
Either by paying for each food separately
or by purchasing prepaid virtual wallet currency
- Provider — a food provider that have access to its panel responsible for:
- Management of food menu, managing the dishes
- Management of availability of the food for current day
- Getting instant notifications of the orders
- Getting daily PDF reports which are printed for provider chef and delivery driver.
- Manages whole process eg. new schools and providers
Business process. Tuszamas unique idea.
Business process was quite different then standard food ordering. First pitfall is that each school has a big break different time, starting from 10 am to 12.30 pm. Food must be order at least one hour before this occurs — provider needs time to prepare exact amount of dishes and to deliver it on time. The other bottleneck was delivering, during the break there is no time to give each dish to particular pupil. Provider leaves all the dishes signed with username from the application and kids only collect their food. Here is an example movie how does it work.
From technical point of view we have described the process in UML diagrams below.
We were commissioned to do the following:
- Advise the whole idea of the application. Define the pitfalls and bottlenecks
- Define business process
- Design whole corporate identity.
- Create the minimum viable product (MVP) with just enough features to satisfy early customers, and to provide feedback for future product development.
- Validate the idea and consult future steps
- Maintain the application and add additional features
The main feature of the app is that is had to work in real time, the time that app is working 90% is between 7am and 11am — when clients order the food. We decided that meteor.js would be perfect selection of technology for this task.
Why meteor.js ?
- Reactive programming out of the box
- Thousands of npm packages
- Lots of magic, syntactic sugar, cli tools, etc
- Meteor official support for blaze (subset of handlebars), React and Angular.
- Easy to learn, ability to build prototypes right away without too much effort
- Build in Cordova support.
First we defined the business process in forms of text documentation and UML diagrams. After that we knew exactly what the app was suppose to do.
Design process. UX and visuals.
Secondly we went though UX process — creation of persons, making the prototypes and mockups. Once this was done, we passed whole documentation to the graphic designer.
Next step was to design a logo, select main colors, fonts, whole visual impression of the brand — that were dark backgrounds, orange text and display typography. We tried to get the impression that this is high school pupils app. We used microcopy a lot. Illustrator provided few characters we used for the whole design.
After about 2 months of intense programming in Scrum methodology and few weeks of testing we had application working. This was our first bigger project in meteor.js so we had to learn a lot which was harder then now — back in those days meteor.js community was not as big as now. It was delivered on time — just at the right moment when school starts in September 2015. The app was ready to validate the idea for few schools in Tricity area.
- Continuous Integration features
- Production application build from master git branch
- Staging server build from `develop` git branch
- Unit test run on each feature branch
- Kadria instance to measure the app performance
- Daily PDF reports for providers
- Custom PDF and CSV reports for given criteria exported in real time.
- D3 statistical diagrams
- Cron email for providers. Email is sent one minute after order deadline
- Three types of privileges — administrators, providers and clients
- Daily backups with strong password send to client
- Google Maps API address verification
- Virtual wallet
- Sophisticated order process based on each school and provider specific deadline
- E-payments (based on Przelewy24)
- Codrova iOS and Android app.
- Deployment process is based on gitlab with its Continuous Integration features. I’ve written the whole article how this was achieved — see resources section at the end of the article.
- Git flow for collaboration and scaling the development team.
- The application use Digital Ocean Ubuntu machine.
- We use own Kadria instance to measure the app. To see how to install own Kadira see resources section of this article.
F***up. (yep we’re not perfect)
Those were really hard moments for us — one day everything just exploded. Server CPU resources were higher than 100%, app was not responding even when we brought additional cores and memory. Client was losing money and reputation so we had to spend few days and nights on debugging and fixing. After all we fixed the bug (too much data processed at once from MongoDB, badly implemented pagination, etc) and right now we believe that the app is scaling perfectly.
From this lesson we know that except of unit test, stress tests are essential as well. Kadria was really helpful to fix this. Here I want to thank Sebastian, developer I found on LinkedIn, who helped me a lot that time. This is what the client said about this in our Clutch review.
What did you find most impressive about them?
We had a crisis with our database about a year ago. Qunabu sorted it out and now everything works properly.
After two years of successful running client decided he want to introduce this as mobile app in addition to web version. Fortunately this was quite easy to achieve since meteor.js has build-in Cordova support. After several weeks of programming we’re able to push the prototype to Google Play and Apple App store. Apple had problem with payments and whole business process but after arranging the call with their validating team — we described how it works and they have passed it to the store. Since then its available to download.
For the moment of creating this article Tuszama application —
- Covers seven main cities in Poland
- 17 providers delivers food
- Pupils can order food in 46 schools
- There are 4400 registered users
- More than 19000 orders were processed
We’re still working on this project continuously improve it features. We work in Time & Material for Tuszama — we talk on Slack channel, we estimate task in Redmine and incessantly improving application.
Below are some random layout screen shots from web version of application.
Our review from the client.
We got really great review from the client, who gave it on clutch service.
What evidence can you share that demonstrates the impact of the engagement?
We have around 5,000 customers and we’ve received around 18,000 orders in the last two years.
How did Qunabu Interactive perform from a project management standpoint?
My investor suggested switching our provider for website work, but I told him that even though Qunabu Interactive may give longer estimates than other companies, their delivery is fine. Other companies will promise to deliver in one or two weeks, but they never do. I prefer to work with someone who gives me realistic timelines. If Mateusz tells me that something will take two weeks, it will.
- Deploying Secure Meteor Application with Test stage and Landing Page on Ubuntu and Apache including Continuous Integration deployment based on Gitlab. Part 1
- Tuszama on Qunabu Interactive
- Tuszama owner review on Clutch
- Setting up Kadira on a Ubuntu 16.04 Server part 1 by Michael Lazarski