Last week, we figured out what it is we actually want to build. Now, armed with a killer idea, we’ve got one more step to take before we can really start thwacking away at the keyboard and creating our indie masterpiece.

There’s a great concept in cooking called mise en place, which basically says that it’s crucial to have all the required tools and ingredients neatly laid out in your workspace before you start making any food. By keeping things clean and decluttered, and by ensuring that everything you need is within arm’s reach, you give yourself the mental space to focus on the creative and skillful bits of the job and avoid dumb mistakes.

I love this concept. It makes cooking a whole lot more pleasant, and it can be usefully applied to a bunch of things that have nothing to do with cooking. Think of the difference between a clean, decluttered desk on top of which everything you need is neatly arranged, and one that’s full of old junk, where you can’t find the notebook you need, the desk lamp is flickering and your mouse’s battery level is at 3%. Which are you going to do better work at?

This post isn’t about cleaning up your desk. (Although, hey, never a bad idea.) Rather, I think there’s a simple but useful way to borrow this idea from the world of French cuisine and apply it to a brand new Xcode project.

Creating a new project is exciting as heck. Think of the unexplored possibilities! The boundless potential! Zero technical debt! It’s tempting to jump right in and starting pounding out what is, surely, the best code you’ve ever written. But if you ever want to become the Michelin star chef of indie app development you’ve always dreamed of becoming…consider first devoting a few minutes to your mise en place.

Of course, building an app is nothing like following a recipe. Unlike most cooks, we rarely know every tool and ingredient we’re going to need ahead of time. Nonetheless, putting some thought into setting up a project that feels tidy and includes a few go-to tools can help get the mundane and annoying parts of app development out of the way, and allow you to focus on doing your best creative work right off the bat.

What exactly your setup should look like is entirely up to you, and depends on what makes you feel comfortable and efficient. But, as an example, here are a few simple things I do with any new project I start to help me hit the ground running.

Tweak the template

When you create a new project, the files that are created automatically are full of comments. They’re helpful if you’re new to this stuff; otherwise, they just take up a bunch of space. Delete! I’m also not a huge fan of storyboards — not a value judgment, just a personal preference when I’m working solo — so I typically get rid of the storyboard file, and instead get my view controller hooked up by adding it to the window in my SceneDelegate. You do you.

Add SwiftLint

SwiftLint is a simple but indispensable tool for maintaining good habits when it comes to code style and convention. It’ll encourage you to keep your code clean and consistent, which I think is a crucial thing to strive for from the very first line of code you write — getting into bad habits early on will always come back to bite you down the road, even if the code is all yours. That said, it’s also important to be a bit pragmatic about style guides, so don’t be afraid to use SwiftLint’s many configuration options to fit it to your needs. I’ve got my own .swiftlint.yml file that I use as a starting point for any new project.

Set up third-party libraries

I’ll start this section with a caution: there are a lot of good reasons not to overdo it with third party dependencies, and I’d be especially careful not to prematurely add libraries you think might come in handy. That said, maybe there’s a simple library that you love using and that‘s generally useful to you in all your projects; if so, now’s the time to get it set up. At the moment, for me, that library is Cartography: a beautiful little DSL for setting up Auto Layout constraints programmatically. A lot of fun people have a lot of fun opinions on whether Auto Layout is bad, whether it belongs in code or in Interface Builder, and whether using a 3rd party library for constraints is misguided. Personally, I love Auto Layout, I’ve been building good chunks of my UI programmatically of late, and I’m a big fan of Cartography’s simple declarative syntax. In my own personal projects, it’s a no-brainer. Your mileage may vary; use the tools that make you feel comfortable and productive. (And, uh, maybe best saved for another discussion, but do try to make sure your dependencies are actively maintained, and that their discontinued existence won’t submarine your app.)

Note: For the first time ever, I’m using Swift Package Manager to manage dependencies instead of CocoaPods. And speaking of mise en place: as much as CocoaPods has been a fantastic tool for many years, I must say it’s a joy to be rid of some of the clutter that CocoaPods introduces into an Xcode project. Worth checking out if you haven’t already 👀

Add any personal tools

I also have a few of my own bits of code — mostly simple UIKit and Foundation extensions — that I tend to import into any new project I start. These are largely straightforward things like factory methods for creating commonly used UIKit objects, methods for applying good-looking shadows to views, shortcuts for adding and removing child view controllers to containers, etc. It’s nice to build up your own personal library of these sorts of tools and helpers that you can then modularize and easily take with you into any new project you start. If this isn’t something you’re already doing, consider this the next time you find yourself extending functionality, creating a new type or solving some sort of general problem: might some version of this piece of code be useful in a future project? If so, it might be worth spending a few extra minutes polishing it up for general use and popping it out into your own personal toolkit.

Get git going

Finally, once all this stuff is set up and ready to go, it’s time to commit your changes and push them to Github (or wherever you happen to be hosting your repo). Make sure you’ve got a good .gitignore file (here’s a good template) to avoid pushing unnecessary junk. Write the perfect commit message, and revel in the satisfaction of the first of many squeaky clean commits!

Admittedly, everything I listed above is, at least for more experienced folks, pretty straightforward. And to be clear, the point here isn’t that adding SwiftLint three commits in makes you tangibly worse off than adding it right away. The point is simply that on the whole, I think there’s real value in spending a bit of time up front thinking about what you’re building, and setting up your environment in a way that neatly accommodates the work you’re about to do. It’s only going to get harder to keep things tidy and intentional as your project grows in complexity; might as well start off on the right foot 🏃

That’s step 2 in the books. Isn’t this easy? We’ll have our indie hit shipped in no time. I’d love to hear your thoughts on this one: got any tools or tips for starting up a brand new project? Do you think any of this even matters? Find me on Twitter if you have any questions or thoughts 🐦