Startup Manifesto

The European Startup Manifesto is a document outlining 22 actions, which combined, should “increase the chances of success” for flourishing and already established technology businesses in Europe.

The document itself calls all stakeholders to share their views and opinions. Here, I state mine about four particular points.


Make it easy for companies to hire outside their home countries.

Four years ago, bringing talent from outside the EU was not easy, but doable. Today is almost impossible for companies to hire non-EU residents. It’s a long, bureaucratic process with close to none odds of success, so most companies don’t even bother trying.

But if developers don’t come to you, you should approach them. There’s a massive amount of talent in countries like Poland, Romania and Czech Republic, to name a few, where the cost of living is lower compared to the rest of Europe and could be very attractive for start-ups to establish technology bases or satellite offices there. Paying above average salaries, getting top-notch talent, keeping costs low and reducing burn rate.

I wonder why these countries have not taken further steps in that direction, they just stare perplex and watch the brain-drain.


Make it easier for companies to let employees go.

This could be a good thing for start-ups, but we are not there yet. What can you do? Improve your hiring process, customize it to your needs so the employee turn over rate decreases. No one has mastered the interview process and no one will.

In the US, is not uncommon to see up to $20K sign up or referral bonuses. Set that money apart for the worst-case. That is, if you need to pay an under-performing employee his or her severance package. There are no sign-up fees in Europe, establish a sign-out fee instead, but keep it to yourself. It’s the cost of doing business, if you do it well, you won’t have to pay.

Take risks, don’t be afraid to hire someone you are not 100% sure about hiring. As long as your recruiting process is good, the false positives should be minimal.

Re-structure your engineering team so that if people is needed to let go, the impact on productivity be minimal. You don’t need more than 4 months to know if someone is a good fit for the company. Hire fast, but fire faster.


Tax share options as capital gains, not income.

Regarding talent acquisition this is a non-problem. Why? Because ownership sharig in Europe is not as common as in the US.

Like the rest of the manifesto, this particular point is written with top management and founding members in mind. But what about the rest of the people? European start-ups need to be kind and give back. Set aside employee options when building your company, as much as you can. With time, this will become an important decisive factor for potential employers to invest in you.

The tax burden and legal fees in which companies have to incur to share the wealth is also significant. I don’t see that particular point in the manifesto, but is something that could also be considered.


Our cultures celebrate celebrities and athletes, musicians and actors. Entrepreneurs who make a real impact on peoples’ livelihoods need to be celebrated too.

Please, NO! Focus on your job, make your actions speak louder than your words. If you are doing it well, you’ll get there. Create wealth, well-being, innovate, change the world, but don’t aim to be a rock star from the beginning. That’s the wrong order of doing things.

Serving static files with Google Drive and the base tag

As a developer/entrepreneur sometimes you face the challenge of building the fastest possible website with the limited set of resources flourishing companies normally have at their disposal. The nicest dream and worst nightmare of a startup is being on the frontpage of a popular online publication, like Hacker News, Reddit, Techcrunch, you name it. Well… Google Drive is here to help.

You probably know this already: Google Drive lets you publish your content online for the whole world to see. Did you just launched the 1000th language that compiles into Javascript and Hacker News is going bananas about it? Just create a shared folder and put all your static content in there, all of them: Images, CSS, Javascript, videos, even the favicon.

Follow the instructions and share you contents. I am skipping this part, because this link explains it very well.


That’s it, now you have your website hosted in Google’s Content Delivery Network available at blazing fast speeds from more different geographic locations than you have ever visited, but with the ugliest possible URL. This is when you login to your $15 a month VPS and modify your index file, setting the “href” attribute of the <base> tag to the directory component of your GDrive shared URL:

Public shared content URL

Public shared content URL

 

Set your base as the Google Drive directory

Set your base as the Google Drive directory

 

All the static content (except your index file) is now being served from Google, while keeping your custom domain and all the SEO stuff that you cared so much for.

If you haven’t done so, put some reverse proxy like Varnish in front of your index file to speed it up a little. Stop worrying about transfer speeds or limit caps for the content served from Google.


Caveats

The biggest immediate peat peeve you will notice, is that all of Google Drive’s content is served through https. Older browsers will complain about mixed secure and insecure content, but come on… we are publishing a website about yet another language that compiles to Javascript! Every visitor will be using cutting edge browser versions.

You could also host your index file on https, but remember, we are a cheap startup that can not even afford an SSL certificate.

The <base> element is available since HTML 2.0, all browsers support it. But we know that not all browsers implement the specifications in similar ways, so be prepared to deal with some abnormal behavior in IE

Image credit: BuzzFeed

Image credit: BuzzFeed

 

Some of the issues you may encounter are already covered in Stack Overflow questions like this one. Take a closer look at them.


QIWA (Questions I Would Ask)

Do you really need the <base> tag?

I know, you can just point directly to each one of the images, css or javascript files in your src attributes and forget about IE misbehaving. But this post title wouldn’t have been interesting without <base> in it.

Does Google impose any limits on sharing from Drive?

I couldn’t really find an official statement about it, but this forum post scared the hell out of me. I assume that if Google has a “publish your website” feature on Google Drive, they can stand a decent amount of traffic. There’s another long thread where people state that the limit used to exist, but not anymore, though.

If I make it to the front page of Hacker News, I’ll tell you ;)

Prototyping In Code Is Underrated

One part of the Software Development Process is prototyping, the step where the user interface and interactions are put to test. I wonder if a napkin drawing, static visual, mocks or templates transmit with accuracy how the final product will work? I’d say no, otherwise prototypes would be called “final product components”.

Early paper prototyping for Madrid Bus App

Early paper prototyping for Madrid Bus App

 

A common belief is that Prototyping in Code is costly. Developers’ time is very valuable, and we can not afford going back and forth coding each different iteration the product owner comes with.

The other day, while at GA in New York, I talked to Paul Canetti. This was on the same day Apple announced iOS 7 and he seemed very excited about it on Bloomberg. Among other things, we talked about prototyping. I usually do some basic prototyping on paper, before starting development, but then move on to do most of it in the code itself.

I always saw my lack of traditional prototyping as a bad practice, a weakness, and told Paul it was something I wanted to fix. He replied with something in the line of “…most people don’t prototype in code, because they can’t code”. We kept having an interesting discussion about the topic, but that phrase clicked on me. It was something that, as a developer, I always took for granted.

Code Prototyping for MadridBus App

Code Prototyping for MadridBus App

 

Having the ability to prototype in code is a gift, and we should take advantage of it. At least developing for iOS, I see a big advantage, and I’m sure other platforms can benefit from it as well. Prototyping directly in code can be far superior than other forms of prototyping. The set of available tools for iOS make it easier and less time consuming. Interface Builder and Storyboard allow us to have a real representation of how the final result is going to look like, test it on actual devices and take them for spin in some contextual tests out in the wild.


I know what you’re thinking: this is iterative development! Not exactly, iterative development assumes that your product functionality is already defined before starting to code, making incremental progress towards achieving the proposed goal. Code prototyping can completely change the direction of your app in an early stage, based on context experiences that paper, mocks and Omnigraffle can’t reproduce.

Code Prototyping allows the developer to better understand user objectives and other stakeholders to get better input of real scenarios early in the development process. Those iterations should not impact final delivery dates, on the contrary, they are an investment towards a more solid product reaching a higher level of maturity sooner than what it should.

My First Post About My First iPhone App

It’s been now almost three months since I got serious and wanted to cross the “Learn iOS development” item off of my to-do list. Two months worth of work derived in my first app, and I’d love to share some facts and objectives that I’m pursuing with it, along with a timeline screenshot of the app’s evolution.

The App: Madrid Bus

I’m currently in The U.S., but before, I lived in Madrid for a little bit more than six years. I was very accustomed to using public transportation, buses, to be more precise. Bus service in New Jersey —where I’m staying— is not as good as in Madrid, but it’s way better than you would expect it to be in The U.S. when two thirds of the population own a car[1].

Well, I had the simplest idea of making your bus waiting at the stop less anxious, by developing an app that tells you how long the next bus is going to take. Sadly, this information is not still public on the NJ Transit API. Then, I decided to capitalize on my tenure in Madrid and build the same idea for the beautiful city that embraced me during all those years.

Thanks to the Municipal Transportation Company of Madrid or EMT, this is very easy for developers. They have a solid, reliable API, with tons of information and an open program that allows anyone to use it. So I went for it!

Another Transportation/Bus App?

I had tons of different ideas for my first app, but most of them involved a backend system. Some were simple, some I wouldn’t call simple. But having a backend involved dedicating economic resources to its maintenance, which I didn’t want to do. Since the beginning I had the full conviction of making my app available for free, thus, minimizing costs and maintenance time was one of the goals.

Many bus stops in Madrid have electronic displays that tell you how much the bus is going to take. But not even the 5% of stops are covered, this is a feature I wanted myself, so I started building it!

Electronic display in selected Bus Stops

Why free?

I have no economic interest in this, is just pure altruism. I guess most developers feel that special sentiment of greatness, being able to put their work on other people’s hands. Building this app has cost me money and I’m not expecting any material gain off of this.

Also, I’m just learning. This is my first experiment on The App Store. I hope more will come, but for now I just want to feel the good developer / bad developer feeling: I hope that some people download my app and rate it, some rates are going to be hurtful, some joyful :)

But there’s already an app for that!

I know, and I want to make a better one! Users are probably going to complain about transit directions or route maps, but I’m not competing with Google, who already does it, and they do it very well. I want to make sure that MadridBus leverages all other apps it can benefit from. Spoiler alert: MadridBus doesn’t do transit directions, but facilitates the process of finding them.

I also want to have a special focus on accessibility, which is a field that unfortunately most developers ignore. I think I have mastered the Accessibility API, so let’s see how it goes.

I’ll make a second, and perhaps a third post about all I wanted to share about my first app. I’m very excited about it and I hope it goes well.

On the meantime, I’ll give you some screenshots and a link to the work in progress website, locate at madridbus.co. Please, feel free to give your feedback, I’m open to bad criticism and and way more than open to good one.

Some iterations on the circular timer before the final result