This is a post in the SaaS Startup Series. Check out all posts in the series here.
The most straightforward and probably also still the most widely used way to set up a PHP development environment on a Mac is MAMP. I used it for years for Wordpress development and it served me well enough. But with this current project my needs have become a bit more complex. While MAMP would still be a workable solution, there are much more convenient and efficient options.
It's always desirable to have your development environment reflect your production environment as closely as possible to avoid headaches during deployment, finding bugs, etc. Since our Web app is going to run on Ubuntu, a Mac can only be a close approximation at best. Ideally, the development machine should be Ubuntu too, but I'd still like to be able to use all the tools I like to work with. That's where virtualization comes in.
Tools like Parallels, VMWare Fusion and VirtualBox make it easy to run instances of Windows or any kind of Linux distro on your Mac. This is not new, of course. What is rather new, though, are tools like Vagrant that make setting up and managing a VM as easy as pie. With the preconfigured Homestead VM box, getting a development environment with everything you need for developing a Laravel application set up is a matter of minutes (depending mainly on how long it takes to download the rather large image file).
We're still in the early stages of development right now. I'm still learning the framework and all its tools, so I expect to move around and throw away large parts of the code I'm currently writing.
At this point I haven't committed the project to a version control system yet, but once I have the feeling I'm generally on the right track, I'm going to put everything in a private Bitbucket repo which I also plan to use for deployment.
Why Bitbucket and not Github? Simply because Bitbucket offers a free plan for private repositories, while Github is only free for open-source projects.
I'm currently on a 30-day trial of PHPStorm. This is more of an IDE than a mere editor and comes with many integrated features for code inspection, powerful autocompletion, debugging, version control and more. It still feels a bit weird because, for one, it's a Java app and those always feel a bit weird to me. Secondly, the default keyboard shortcuts aren't what I'm used to from other editors. But like almost everything else they're completely customizable, I just haven't gotten around to it yet.
The other options would be Sublime Text and Vim. Both are certainly powerful editors that could probably be equipped with at least some of the features of PHPStorm through plugins. But right now I don't really feel like trying to get them to do what I want when PHPStorm already has everything I could possibly need out of the box.
So for now I think I'm going to stick with PHPStorm. The cost for the license (199,- Euros for a commercial license with 1 year of support and updates) should save me a considerable amount of time during development and testing. Plus I probably won't need an extra Git client like Tower (certainly looks like a great tool though).
Helping ecommerce entrepreneurs set up their Shopify stores has developed from more of a hobby into a growing sideline in my business. After setting up my own store back in 2012 I started helping others do likewise in 2013. Before I knew it, I was getting inquiries to set up stores, tweak designs, install and configure apps, etc. These days, I'm getting multiple inquiries a week and I haven't even really started marketing my services yet.
With now multiple clients and projects at different stages at the same time, I needed a way to keep track of it all. At first I thought I could just use Excel, but that proved unwieldy pretty quickly. I checked out proper CRM systems but quickly realized that they're way too complex (and in many cases, expensive) for my needs. Then I found the perfect tool: Trello.
In Trello you put cards on lists. These cards can contain text comments, labels, due dates, checklists, attachments and more. Lists are collections of cards that you can drag around to your liking and you can drag and drop cards between lists too.
As simple as this sounds, it's near perfect for setting up a sales process and keeping track of client projects. Here's how I have my lists set up, from left to right:
- Clarify Requirements
- Quote / Estimate
- In Progress
- Check Payment
- Ask for Testimonial
- No Deal
Each card represents a (potential) client and the complete history of our relationship. When a potential client contacts me for the first time, I either add a card to the Incoming list, or, if the client contacts me via email, I forward that email to a special Trello email address and the card automatically gets added to that list.
When we're in the process of discussing their requirements, I move their card to the Clarify Requirements list. It stays there throughout this phase and I document the gist of what we discuss in the card's comments. I keep the details in our email discussions or, if they're rather complex, I set up a separate to do list in a folder dedicated to the project.
When the requirements are settled, I move the card over to Quote / Estimate. When the quote is ready, I send it to the client with an estimate, move the card to Follow-Up and set a due date a week or so later. If the project fizzles out at this stage (and it often does, as clients realize my services don't come for free), I move the card over to the No Deal list and that's usually the end of that card and client.
If, on the other hand, the client signs off on the quote, I move the card over to In Progress and get to work. It stays there until the project is done and then gets moved over to Invoice. Once I've sent my invoice, I move the card to Check Payment, and if my invoice doesn't get paid within a certain time frame, I follow up with the client.
Once the client has paid, I move the card to Ask for Testimonial and follow up with the client, kindly asking for a thumbs-up on Shopify Experts. Then the card gets moved to Done. If a client returns later for a follow-up project, I just move their card back to Clarify Requirements and it all starts over.
I've been using this process for a couple of months now and it's working better than I had initially thought. I was afraid it might be too simplistic and wondered if I'd be able to track everything I thought I might want to track.
Turns out, all I really needed was a tool that tells me what I have on my plate at any given time. And Trello and my system deliver.
This is a post in the SaaS Startup Series. Check out all posts in the series here.
Back in April 2014 my buddy Austin White and I embarked on a journey to build a web app. Then, as our respective lives got unpredictably busy with other stuff, the plans for our SaaS business had to take a backseat to moving house, plumbing emergencies, other work (the kind that pays the bills now) and more. Now, almost a year later, we're finally forging ahead on our plans.
I plan to (losely) document our progress here as it happens. This first post in my "Startup Diary" will give an overview of the project and where we are right now.
I want to preface this by pointing out that I'm not yet going to reveal what we're working on exactly. Once we're a bit further along in the project, I'll be happy to talk about details.
At this point we've filed for a trademark for our app's name in the U.S. and the EU will follow shortly. We also plan on setting up an LLC, but since Austin is in the U.S. and I'm in Germany, we still have to sort out some details. Finding a lawyer who's familiar with all the legal and tax implications of co-founders living in different countries has so far proven to be quite difficult (and expensive).
In terms of the app, we've agreed on about 80% of the features we want to include in what we're calling our MVP. We've sketched out and wireframed parts of the customer-facing UI, created an ERD we'll use to create the database and decided on the technology we'll use. So let's talk a bit about that last part: techology.
We initially intended on outsourcing the development entirely. Mainly because both Austin and I work full-time, which doesn't leave enough time and energy to develop the app ourselves within a reasonable timeframe. So we thought we'd focus on designing and marketing the app and managing the development process.
But an unanticipated development in my consulting business at the beginning of this year means I will have more time available for other ventures. So I figured that, being a developer myself and now having (foreseeably) more time than money available to invest into our business, it would make sense for me to do the development instead of outsourcing it. Austin and I discussed this and quickly agreed on the change of course.
When we were still set on outsourcing the development of the app, it was pretty clear that we were going to use Ruby on Rails. Clear because that's what so many web startups use these days. They can't all be wrong, right?
The picture changed, however, after we decided to do the development in-house. I don't know any Ruby or Rails beyond a handful of tutorial videos I watched a couple of months ago. With all the work we already have on our plates to get our web app to market, I wondered if learning a completely new technology was such a good idea.
In terms of web technologies, I have a bit of a background in PHP and MySQL. I haven't built a real web app before, but I feel fairly comfortable in these technologies and I'm pretty sure I can get results faster than if I first had to learn Ruby.
But it's not really about the programming language anyway. I think the more important part of your development stack that will have a much larger impact on your productivity than the language is the framework you use (if you decide to use one). Obviously, Ruby has Rails going for it. But what about PHP?
Even though both languages have been around for 20 years, PHP has been used more widely as a language for developing web apps than Ruby. So there's a pretty large selection of frameworks to choose from, the most well-known ones being:
- Zend Framework
There are more, those are just the most well-known ones.
What influenced my decision for a particular framework was the fact that I wanted something fresh that had as little cruft as possible. PHP has been evolving for quite a long time, and so have its frameworks. Evolution is good, but it also breaks things. And fixing those things while maintaining at least some level of backwards compatibility can result in a hot mess of old an new paradigms.
I can't fix PHP's flaws, but I can choose a framework that leaves behind the old stuff. And that's why I chose Laravel.
OK, who am I kidding. The truth is, Laravel just looks sexy as hell and now I'm rationalizing my choice. I chose Laravel because it looks like it's going to be fun to work with. We'll see if that holds true over time.
Another thing that really won me over to Laravel is that there's a video tutorial site dedicated to Laravel called Laracasts. Some basic videos are free, full access to all videos costs $9/mo. Well worth it in my mind.
The development environment isn't set up yet, but based on the decision for PHP, it's going to look something like the following.
- Linode with Ubuntu 14.04 LTS
- PHP 5 FPM
This setup is already running on the Linode this site is hosted on. Once we move the app into beta, we'll spin up a dedicated Linode and move everything over. But for now, the existing one will do.
Another major factor that determines your productivity as a developer are the tools you use, specifically the code editor. You're going to be writing and editing (and possibly debugging) code several hours a day, so your choice of editor or IDE is important.
I'm not 100% set on any option yet, but these are the contenders:
- Sublime Text
Right now I'm actually favoring Vim as I want to get to know Vim better anyway.
Some additional tools to make life easier:
- tmux (multiple panes in a single terminal window)
- Vertabelo (web-based database designer)
- Sequel Pro (MySQL client)
- OmniGraffle (business graphics; used for wireframing)
Since Austin and I live in different parts of the world, we need tools in order to communicate efficiently; just email won't cut it.
So far, we've been using these:
We started out using Basecamp and it was OK for a while. But once we started getting more into the thick of things it proved to be a bit too minimalistic. Asana is a better fit for our current needs and it's also free for up to 15 users (Basecamp is at least $20/mo).
It's still very much early days with our project, but I feel we're gaining some traction after stalling in the beginning. But I'm also aware we've still got a long way to go. But if it were easy, everybody would be doing it ;)
This is a post in the SaaS Startup Series. Check out all posts in the series here.
This place has been a ghost town since April. Given that one of my goals for this year is to write more on this blog, this is embarrassing. Fortunately, what kept me from writing is now (more or less) out of the way and I'm slowly finding my way back into working on my projects.
Since late April I've been as busy as I've never been before moving to a new place. I decided sometime in the beginning of the year to move closer to Munich to make my commute more bearable. Having lived in the same spot for close to five years, I was also due for a change of scenery.
The original plan was to start scouting for a new place and get a feeling for the market in Munich throughout Spring and then move later in the year, leaving me plenty of time to declutter and pack everything. But after just 2-3 weeks of looking around I found a place that I immediately fell in love with. It's not within the city limits of Munich, instead it's located in the beautiful Lake Starnberg area. Unlike the village where I previously lived, it also has nearby access to a highway, so my commute is now half of what it used to be both in time and distance. Something closer to or in Munich would have been even better, but an apartment like this one just doesn't exist there (more on that in a future post).
I signed the rental agreement in late April, scheduled the move for the end of June, leaving me just two months to downsize from an 1800 square feet house (full of stuff) with a 700 square feet basement (also full of stuff) to a roughly 1300 square feet apartment with a small 60 square feet storage room.
Rightsizing, aka Throwing Crap Out
Cutting back on the size of my home is part of one of my goals for 2014: To simplify my life and own less stuff. Just the fact that I don't have a huge basement anymore means that anything I own will have to go either in the very small storage room or into my living quarters. Since I don't want to live among tons of crap I don't need, this is a great way to help me stay rigorous about what I buy and what I throw out.
I spent the better part of April, May and June decluttering the house room by room, sorting out (probably literally) tons of stuff including old hardware, books, DVDs, papers, tableware, furniture, gardening tools and more. The stuff I threw out filled the twin garage that belongs to the house. I had a guy pick up the bulk of it, but I still found yet more stuff to throw out over the following weeks and did at least half a dozen trips to the local dump. I did all this while commuting to Munich to work three days a week, so I was limited to evenings and weekends.
On the one hand, this was an unsettling experience. With each thing I threw out, I felt reminded of how much money I had spent acquiring it and how much energy and, again, sometimes money I was now spending to get rid of it. I hope this will make me rethink future purchases, especially (physically) larger ones that are hard (read: expensive) to get rid of.
On the other hand, getting rid of so much stuff felt liberating. It's like the clutter used up mental space in addition to the physical space in my house. I knew I had to get rid of a lot of stuff just due to the fact that my new place is considerably smaller. But I also took a critical look at each and every piece of furniture from the point of view of whether I actually needed it. Previously, I had employed the (ahem) strategy of keeping things around that I thought I might eventually need. After all, I had a huge basement where I could store all this stuff out of sight. Now I only kept things I had used in the last 1-2 years or so, thinking that if I hadn't, that wasn't likely to change. So I wasn't just downsizing to fit everything into the new place, I was what some people call rightsizing.
Getting Back On Track
Now the move is done and all boxes are unpacked. And while there are still some pictures to hang and some decoration ideas to try out, I can finally get back to working on my goals for this year. The move and decluttering were part of my goal of simplifying. My goal was to get rid of half of my stuff so I could live in a place half the size of the house. While I didn't declutter or downsize quite so radically, I'm putting a checkmark next to that goal. Which doesn't mean I won't continue to "rightsize".
But rightsizing itself doesn't do much in terms of moving me towards my other goals and the move took up way more time and energy than I had anticipated. So the second half of 2014 will be just as busy as the first half, I'll just be switching from physical work to using my brain more. I hope it still works.
I've got a book to write, which got a lot more challenging with Apple's announcements for iOS 8 at WWDC. Austin and I need to get serious about our web app, I want to get the beta of an iPad app I'm developing ready (and probably rewrite the little code I've written so far in Swift) and I need to reboot Think, Make, Sell which has been on hold during the last couple of weeks simply because I didn't manage to keep it going during the move. And, oh yeah, the GroovBoard 2, that's also on (more on that in a future episode of The Maker's Journal).
If I make an honest assessment of everything that's on my plate, I'm pretty sure that I'm not going to hit all my goals for this year. But I'm not going to let that discourage me. Whatever I get done by December 31 I'll consider an achievement, and whatever remains to be done will go on my list of goals for 2015.
In this episode of Think, Make, Sell my co-host Austin and I talk about how our holiday sales went and the lessons we learned over the years regarding shipping (like: shipping to Russia can be...interesting) and customer service. And there’s finally some progress to report on the GroovBoard 2.