Long time readers of this blog know that entrepreneurship and tech are the closest to my heart. At last, I’m trying to do something about it.
I’ll attempt to fix 100 tech projects by the end of the year.
Starting small, yours truly is going to help London’s non-technical founders first.
Eventbrite link here, more details coming soon, hang tight.
(Also, could you please help out by sharing this? Events are just such a hard thing to pull off.)
When you hire a freelancer to write a mobile app, that person likely has written many apps before. They will have a good handle on how long the project would take, or how much they need to charge you to make a profit.
Research and development projects are rather different, because with those you never know how long the research part would take before you come up with anything useful. Managing R&D projects is difficult, outsourcing is even worse (but, none of those is impossible).
Most artificial intelligence projects you’d want to do these days are heavily front-loaded. A lot of thought and effort has to be put into the first iterations, and you’ll only get to see the result much later. Even the simplest and most generic recommendation engine can be derailed by a perfectly normal looking site’s perfectly clean data, if that particular niche or traffic is less predictable than others.
Artificial intelligence projects mostly fall in the R&D category then, which is alright because yours truly just wrote an advice piece on Managing outsourced machine learning projects. Read it over at the RemoteML blog.
We are also happy to give advice to companies manage outsourced R&D, so do feel free to give us a call!
People tend to overestimate how hard it would be to replace them. Many managers push back their retirement date thinking that the company would die without them. While it’s true that transformation is rarely easy, it’s almost never impossible either.
I wrote this as a case study for our corporate website, but removed all names or sales pitch for this platform. Publishing it on my personal blog for the education value, and to spark conversation.
—
The local transportation authority of a USA state capital developed a new website and mobile apps for commuters to receive realtime travel information, or get around easier. Then they received a letter from a lawyer.
A visually impaired user wanted to take them to court, because the new apps lacked accessibility controls. It was impossible to navigate, the colours didn’t have enough contrast, the apps needed a top-to-bottom overhaul. To avoid having to go to court, the company had less than 12 months to bring in a new team and roll out completely new apps. So they did. The works started in January.
The new team then left in September, just after 9 months in, and leaving a little more than 3 months to find a solution. The project was abandoned, and so close to the deadline, the only choice seemed to be to remove the transport apps from the app stores altogether. In the end of the day, if there’s no app, there’s no need for it to be accessible either, and no-one gets sued.
“A goal without a plan is just a wish.”
– Larry Elder
We joined the team in October with the promise to roll out the app in the very end of December. We applied two massive changes to the project.
These two changes allowed us to move really fast, and provide our client with more than just weekly progress updates: they could test the actual app developed, and had a huge impact in changing it with their feedback for the better.
Everything’s well that ends well: the apps were both released on schedule and in budget, on the very last workday of December.
One of my favourite puzzles is this one, from the 1930s:
Three people check into a hotel room. The clerk says the bill is $30, so each guest pays $10. Later the clerk realises the bill should only be $25.
To rectify this, he gives the bellhop $5 to return to the guests. On the way to the room, the bellhop realises that he cannot divide the money equally. As the guests didn’t know the total of the revised bill, the bellhop decides to just give each guest $1 and keep $2 as a tip for himself.
Each guest got $1 back, so now each guest only paid $9, bringing the total paid to $27. The bellhop has $2. And $27 + $2 = $29 so, if the guests originally handed over $30, what happened to the remaining $1?
Try to solve this without any further hints.
Obviously, there’s a trick.
The misdirection in this riddle is at the end of the description, where a bunch of unrelated numbers are added together – only to misguide the listener.
There’s no reason to add these random totals, and even less reason for the sum to add 30. If you wanted to sum up the cash total, you have to look at the $25 in the register, the 3*$1 in the guests’ pocket, and the $2 with the bellhop. That’s, as expected $30.
More missing dollars on Wikipedia.
Snapchat started selling Spectacles, their $150 sunglasses with the built-in camera. Whoever is wearing them can essentially: take a short video of anything and anyone without much notice and upload it to the Interwebs right away.
Sure, it’s only 10 seconds of a video, and their usage is very limited, and the quality is crap and and and.
But you know where the future is heading.
In a few years’ time, everyone and everywhere will record everything. Just like we all have mobile phones that follow us everywhere, we will keep glasses with ourselves at all times. I know I will. You know you will, too.
The content will also be searchable, with tags and location and everything. You can ask: “hey, Internet, what’s going on right now in my hood?” — and there you have it, someone’s live stream.
It’s not what we want. It’s what technology wants. When Google came out with the Glass it wasn’t useful at all, but it showed us what the technology could do at the time. We didn’t like the product. It was too weird and clumsy and too geeky, something like mobile phones were 20 years ago.
Now, Snapchat may bring something more fashionable. Something that we might embrace. If we don’t, that’s not a big deal either: you can be sure that in a few years someone else will reinvent the lot.
If there’s anything we should have learned about technology by now is that whatever it wants: will get it.
I like to receive quick-and-simple reports for my side projects in the email inbox every morning. This helps to have a good understanding of the progress, but without paying too much attention to Google Analytics or getting lost in sql queries.
Problem is, for all my projects the KPIs are different. For some apps it is the daily subscriber count, for others a key API’s usage for example. The technical stack also varied a lot: some project were written in Python, some in Node.js and others in Java. I couldn’t reuse much of the code for all those projects.
The solution was to create a super-lightweight external app that extracts the important data points from the database and sends it out in a nice email.
This new open-source project is then a simple tool, where you can create reports from simple database queries, and send those reports out in pretty emails. (I also did one Google Analytics integration for one of my projects, but that code still needs some cleaning-up before it can be open-sourced.)
This app runs on AWS Lambda, so you don’t need to set up servers or worry about hosting: you just deploy the function and add a scheduler on the AWS dashboard to run it. I’ve set it for daily or weekly mails, but it does support all sorts of triggers too.
Source code & quick start guide on Github.
Enjoy!
In my latest newsletter I’ve asked about whether anyone reading this blog needed (free) advice scaling up WordPress projects. I regularly help out friends with their apps and ideas, and the same topics tend to bubble up all the time – maybe there are more generic advices there that you could use too?
Here, the three questions that came up most.
1. How do I find developers?
Apart from a couple of guys I love to work with, I quite often hire people on Upwork. It’s not as easy as it seems actually: a lot of developers are available, good and bad, and if you don’t know WordPress or to code yourself, it’s quite difficult to tell them apart.
My usual practise is to come up with a small enough part of the project, and test the team’s abilities on a development server. For example, instead of redesigning the whole website in the course of a few months, they will just work on a landing page template for two days. If they succeed they are in for the long run, otherwise I only lost a couple of days altogether.
It’s important to mention that at this point the developers have access to only a copy of the project and non-sensitive data. You’d be surprised to know how many professional-looking development companies went on to accidentally delete all data from my (test) databases.
2. How much more expensive is scalable cloud hosting compared to other providers?
To compare, a non-scalable alternative Hostgator starts at $2.78 per month, which you can’t really compete with on the price level. If you never plan to scale the project it might as well be a good enough solution actually.
For apps that need to scale however, you will need to set up database and file storages, and those are to be paid for separately. (Mind you, using an Amazon EC2 instance or any VPS, and then hosting the static files and database there is pretty much as scalable as Hostgator is.)
To avoid comparing apples to oranges then, let’s just say that the maximum amount of traffic you can serve with standard hosting providers can be easily hosted on the smallest hobby Heroku instance as well, for $7/month. Amazon EC2’s smallest instance would cost around $25/mo.
File storage depends on the traffic and the size of the static files: for this blog with ~3000 monthly unique visitors I pay less than $0.1 in a year, but more traffic and bigger files (like hosting videos for example) would cost you more.
Cloud MySQL databases start at $3.5/mo from ClearDB, Amazon RDS starts around $20/mo (though you can use that for multiple projects).
All in all, a small website is around ~$10/mo on scalable cloud solutions versus ~$3/mo on Hostgator. The big difference is that if you suddenly need to support a higher load of traffic, it only takes a few clicks to scale up on Heroku – while Hostgator just slows down.
3. Why am I pushing for Heroku as opposed to Amazon?
Most development companies are familiar with Amazon EC2 and simple VPS solutions. Those are actually excellent products and are very flexible, but the exact reason I like to recommend Heroku is that it’s more strict.
For example, you can only copy files to Heroku via a Git repository, and you can’t access them via FTP. Developers like to argue that they could also use git to push code to an EC2 server. However, they can also just modify the code directly, and if that’s quicker and easier, that’s exactly what they will do.
Developers tend to get lazy and fall back to harmful defaults, like, storing files on ephemeral disks. All those bad decisions would then keep the project from scaling up quickly in the future — but if those options are not even available, at least that’s one less thing to worry about.
When I created my first product, a website content management system, I was still in high school and had no clue what I stumbled upon. It was like WordPress, except that there was no WordPress at the time: it was 2001, and people just learned that you don’t need to double-click on the web for the links to open.
Everyone wanted to have a website and have a piece of this cool new thing, the Internet, and my CMS gave them exactly this. Companies could have a website, put out content on their own, upload photos and what not – pretty much everything you can do on any website now, but mind you: it was 15 years ago, and I was the only person offering this in a 100 kilometres radius.
It spread like wildfire. Everyone wanted my stuff.
I was just a clueless teenager programmer with no mentors around, but with a cool product people wanted. I had no idea what marketing or sales was, nor had I a need for that. Within the first year, half my hometown was using the software I wrote – even massive businesses and the network of public libraries. I was riding the biggest wave of my life, not knowing the first thing about waves at all.
Sales looked like: I went to meet a company, demoed the product and they’ve ordered it the next day. Companies gave each other my contact.
One day I went for one of these sales meetings, pitched the product, went home, and started to set up the project. Except that this time the phone didn’t wring.
The sale fell through.
That was an unusual and terrible feeling. As natural as it was for everyone else that, sometimes, people don’t buy the product you’re selling, that rejection was my first and I had no experience handling such.
The competition started to catch up and soon there were other companies, run by non-18-year-olds, that sold similar systems. Arguably crap products at twice our price point, but that didn’t matter: the world has changed, and I had to learn to do a bunch of new things.
Things like marketing, dealing with competition and copycats, and eventually: pivoting with the business. The lot.
As it turned out in the next 15 years, it’s really difficult to be that lucky with any product. It’s really difficult then, to get away with not being good in marketing.
Every company that became successful seems to have had someone on board who was good in sales. Max Levchin started Paypal with Peter Thiel, Steve Wozniak started Apple with Steve Jobs. Just as Apple Computers wouldn’t exist without Woz building their first computer, it wouldn’t exist without Jobs selling those machines.
There you go, a potentially million-dollar-idea from a clueless teenager: find someone who can sell stuff. Or find out how to be that person.
This is another for-fun project: an admin interface in React JS. The package ships with a simple API and is hosted on Github, check it out.
(Unless of course you arrived here from Github, in which case please stay here and try not to get stuck in an infinite loop.)
Django is a fantastic tool to create app backends in literally: minutes, and it even comes with a built-in admin to manage all data on the site. It’s not very pretty, but it gets the job done.
Enterprise clients usually want a better and more user friendly admin interface. Therefore more often than not we end up extending Django with another tool that incorporates all sorts of dashboards and extra features that aren’t just for manipulating the data models.
When you want to extend Django with an admin tool that actual humans can use, you have two choices: tweak the built-in one so that it becomes a little friendlier, or, create another interface from scratch.
The project I’ve created is to create a simple admin interface in a fairly extendable way:
I have yet to update the Github repository with more features, but the one already in is a good start. When I’m writing this post we are just about to release two small projects at my company that have been built on top of this React admin. I’ll report back on how those catch on, but as far as the development goes we’ve been quite happy with the setup.
We can add new features really, really quickly, the product is pretty neat, and in the long run, an automatic Django-model generator doesn’t seem to be impossible either. React JS also turned out to be quite some fun to build software with. It’s flexible enough to work together with jQuery plugins, Bootstrap, Backbone and whatever else we needed down the road.
To make this project more transportable, I used an off-site build. That means that the front-end is literally just some HTML-and-JS static files after the build, and so the hosting is a breeze. You can put it on Apache, nginx, or whatever really, you can even host it from Django’s static folder.
See the screenshots on Github, and as always, ping me on Twitter if you want to chat about this.
A friend of mine is scaling up her website. It’s running WordPress and has ways too many visitors for their stone-age hosting, which means the service is slow and crashes regularly.
I’m trying to help out, and there are low-hanging fruits all along the way, like moving the files and database off from the VPS and into the cloud. Eventually we are going to move the whole lot to a low-maintenance cloud host like Heroku or CloudControl, use nice caches and what not.
There is one massive bottle-neck: developers.
Technology is awesome. Today you can live in a cave and run a website with close to 100% uptime rate for buttons. No kidding, this blog, receiving about 3000 uniques every month, is running on the smallest Heroku instance – with 100% uptime for the 3rd consecutive month, according to Pingdom. Could easily handle ten times the traffic, all less than $10 per month.
Developers are the ones who are not awesome. They are many, for sure. Throw a stone any direction, and it will hit a WordPress developer.
That stone is likely to hit one who is renaming files to php.backup instead of using version control. One who is not reading Hacker News. One who has never heard of the Twelve-factor app.
It’s definitely not because the new technology is too difficult to learn. I’ve just had a 19-ys-old teammate on a London Hackathon who was writing code for Android, Pebble watch and hacked together a website in 24 hours. I’m pretty sure that, if you’re a developer reading this, you can tell the same story about yourself in your early 20s. We are curious people. I think most developers just give up trying after a while.
The friend-of-mine with the WordPress site is now working with a team of developers who look at Heroku and send me e-mails asking for the FTP password. Clearly, they need to go. Is it easy to find a better team? It is not: Linkedin makes it way too easy to copy CVs, the example codes are plugin rip-offs, and no one can pass the simplest of tech interviews.
Without developers though, any tech project manager is just the coachman who whips thin air and wonders why the carriage wouldn’t move.
(I’m helping out a few friends with their side projects these days, so you can expect more of these rant-posts popping up, haha.)