I recently quit working at Grapes ‘n’ Berries, the company I cofounded almost 2 years earlier.
I’ve always heard that quitting your own company is a very hard thing to do, and that was exactly right. My decision to quit though came from the realization that Grapes ‘n’ Berries has precisely turned into the company I never wanted to create, and that I have no control to change it.
I bet you’ve heard a million times that picking your partner(s) is the most important step of starting a company. I’ve unfortunately failed to do so. I found myself in a commitment with a partner that does not share any of the values I believe in, comes from a completely different background, and does not have the same vision of where the company should be heading.
If I had to give some advice to 2-years-ago me, my advice would be:
- Spend lots of time to know your partners very well, why they want to start the company you are starting and what’s their vision for it in the future.
- Non-full-time founders are a no-no. If someone wants to invest money in a startup but doesn’t want to risk quitting their full-time job, they should simply be investors, not cofounders, and certainly not CEOs.
- Before jumping in and starting to do any work, agree on (and document) the equity split, the amount of money each partner is putting in, if any, and what happens to a cofounder’s equity when they leave. I recommend a standard 4-year vesting period for the latter.
- If any of the cofounders is putting money into the company, make sure that this money will be available in the company’s bank account in its entirety from day one.
- Set up a board of directors with an odd number of members as early as you can. The odd number will prevent tie votes.
- Stay away from cofounders whose sole purpose of starting a company is to make money. Maybe recommend real estate to them.
While it makes me sad that I no longer get to work with the great team of developers I assembled since we started Grapes ‘n’ Berries, I was at a point where I could no longer stay in a partnership that’s not aligned with what I want to do.
I’ve seen many tech companies where people on the business side have a complete lack of understanding of what motivates software developers or makes them do the work they do. This results in dissatisfied and demotivated developers that are eventually going to quit and move on to work on something more exciting somewhere else.
While it’s usually hard to put the joy we get out of programming into words, The Mythical Man-Month by Fred Brooks does a very good job with that.
Here is a quote from the book’s first chapter:
Why is programming fun? What delights may its practitioner expect as his reward?
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and find it helpful. in this respect, the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of the principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism carried to the ultimate.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another, the problem is always new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
Finally there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.
I believe that there’s a balance that can be struck between work that engaging, challenging and fulfilling, and work that is financially rewarding. Focusing on either side and ignoring the other results in dysfunctional companies that are bound to drive employees away.
I often work on mobile apps with designers that have a web design background. I see the same set of mistakes being made as they transition from being web designers to mobile apps designer.
Here are a few tips from a developer’s point of view that I believe would make you create better designs and would help the developers you’re working with create better apps.
1. Don’t make teeny tiny touch targets.
People don’t use a mouse on their phones, they use their fat squishy fingers, so adjust your touch targets accordingly. Don’t expect people to be able to tap a 20×20 pixel button that is surrounded by a bunch other tappable elements.
2. Understand the proper usage of UI elements.
Both iOS and Android have thorough UI guidelines that talk about the proper usage of each UI element. Don’t consider yourself a mobile designer if you haven’t read those. Also, it’s always useful to look at how existing apps solve problems you’re trying to solve. Pttrns is a great resource for doing that.
3. Don’t design for a platform you haven’t used.
Don’t design apps for iOS or Android if you don’t use them. Reading the interface guidelines and looking at other apps will help a lot but it’s not enough. You won’t get a grasp of what a good app on a certain platform should be like unless you’ve used that platform for some time.
4. Understand the different screen sizes and the impact it has on your designs.
Don’t be one of those designers that just want to know what size they need to export the images assets to. You need to understand how different screen sizes are treated on each platform and how that would impact your design.
5. Designs are not static.
Many designer make the mistake of thinking of their designs in a static way. Those usually end up with pretty designs that aren’t very usable. Think of the animations and interactions of the app. Think of the different states of each view and how views are going to look like when they are empty or full of data.
6. Learn to code.
It’s not as crazy as it sounds, and no one is expecting you to be able to build complete apps on your own, but dipping your toes into coding will give a better perspective on what’s possible and what’s not and will greatly help you build better apps.
TracKit recently got featured on AppAdvice’s Apps Gone Free. While I knew that this means a nice bump in downloads, I had no idea what numbers to expect.
After the initial launch a year and a half ago, TracKit downloads settled down to a consistent 5 to 10 downloads per day. The day TracKit got featured, I got 8,622 downloads. Apps Gone Free features apps for only one day, but it still created enough exposure for the app to get downloaded 3,032 times the second day, then it dropped significantly during the rest of the week, but still maintaining a higher-than-average number of daily downloads.
Overall, TracKit got around 12.5k downloads as a result of being featured on Apps Gone Free. While it won’t make your app jump into the top charts, it sure gives a nice, appreciated boost.
Depending on your type of app, you have to either make it free or make the IAPs it offers free to get featured on Apps Gone Free, which means no change on revenue, on the short term at least.
Thanks Apps Gone Free.
I’m heavy user of to-do apps, specially Wunderlist, but recently my to-do list started to be a place I dread looking at it. I have too many lists, overdue tasks, things that I need to work on today, things that I need to take care of a week from now, groceries shopping lists, and a plethora of other things.
Simply it was just too distracting for me. Just like the 1000+ unread messages in your inbox right now that makes it impossible to read a message without being distracted by all that noise.
My primitive solution to the problem was to grab a piece of paper everyday, write only the important tasks that I need to focus on today, and ignore the rest of my to-do list for the rest of the day. By the end of the day, I throw away that piece of paper and start the next day with a fresh set of tasks. That approach worked quite well for me, so naturally the next thing for me to do as a software engineer was to turn it into an app.
Focus List does just that. It’s a very minimal to-do list with only a place for tasks you need to focus on today. The list is wiped out clean by the end of the day so you always start with a clean slate next day in the morning (or whenever you tend to start your workday).
Even though Focus List is very simple, I’ve been working on it for quite some time now. Since my goal wasn’t just to ship it, but rather to do some experiments in both the UI and the code along the way, I’ve changed the UI a couple of times and rewritten the majority of the code every time.
Focus List is available on the App Store for free with no ads or in-app purchases. Go grab it now, and I hope it helps you be more productive.
At any given moment I’m always working on a little side project. Some times they ship, usually they don’t (I only have TracKit and Photos Cleaner on the App Store, and one more app in review as of this writing).
Usually when I start telling people about the side projects that I’m working on, they wonder why am I wasting my time on projects that I have no interest in monetizing or that might not even ship. I have a very good reason.
Stupid side projects are always a healthy thing to do. You don’t expect any of your side projects to be the next Facebook or Twitter, or to change the world, but you keep on building them anyway. You build them because they are things you personally need. You build them for education, either about a certain technology or a certain aspect of business.
Since I’m usually not expecting to make money out of my side projects, I skip the market validation part and jump right into building them. That sometimes means sketching it on a piece of paper to make it clearer for myself, or on other occasions it means starting to code right away.
In side projects I get to be as meticulous as I want. I have no deadlines so I get to do things the way I see best, which occasionally means completely scrapping some parts and rebuilding them, and that is always great for learning. I also get to try whatever new crazy technology or language that looks cool but is too crazy to use in my full-time job.
It would be great if a side project turned into something that makes a decent amount of money, but that’s never the intention when I’m working on them, and that’s what makes them very special. I’ve learned a lot working on side projects, and I’ll continue to do it for as long as I have the time.
What stupid (or not so stupid) side project have you recently worked on?