Intro

My curiosity for understanding how things work has been endless from a young age. When I was 12, a friend of my parents who was a programmer asked me a question that changed the trajectory of my life: “Do you just want to be a user and subject to what others have built, or do you want to be a maker and create your own tools and build your own reality?”

This was in 2000. There were no online courses or coding bootcamps at the time. I learnt to program by reading the Standard Library Manual for the C Programming language cover-to-cover twice while on vacation with my parents in Italy. If you want to get a taste of what that’s like, read 500 pages from a dictionary.

I fell in love with programming. How many of us actually know what happens behind the scenes when you turn on your computer? I wanted to know. I found a bunch of other kids in an online chat and we wrote an operating system together. If I had to compare it to something relatable, I’d say it’s like making a cheeseburger by first growing a cow and making your own cheese.

I didn’t stop there. There was an endless variety of technologies to explore. I didn’t just want to know how to program, I wanted to learn how to make things look good, too, so I learnt 3D modeling, web design, etc. I taught myself other programming languages just to satisfy my curiosity.

People started reaching out to me to build WordPress sites. I co-founded an ed-tech startup in college, where I learnt to work with large organizations and lead teams of developers. Then I started an agency – gunpowderlabs – to help startups and eventually established businesses build their apps. That was 10 years ago. Over that time, I’ve modeled the best in this industry and developed my own process.

I think that’s what makes me unique. I speak tech. I speak business. I can do design. I can write. I am an entrepreneur, so I know how to help entrepreneurs. I can execute an entire project myself, from strategy through design & development. And most importantly, I’ve never been taught. I learned how to learn. Learning is a superpower.

I may not be the best in any one of these disciplines, but I’m the best at their combination, which gives me the unique ability to kick projects off, set them up for success, and bring in the experts in their disciplines to execute them.

These are the principles and practices that I use.

Key Outcomes

Framing a project correctly is vital.

Most clients approach me with a feature list. I’ve found that building everything the client wants rarely ends well, unless they are master app builders themselves.

Rather than just building things, I help my clients make an impact on their business, with a world-class level of quality, while having utmost confidence that they’re on the right path every step of the way.

• Impact is usually a financial return on investment. It can be “generate $X in revenue”, or “save $X per year by automating Y”. Sometimes it’s less tangible, like “make our residents' lives more convenient”. This is the project’s north star that aligns everyone on the team towards rowing in the same direction.
• Quality is how well we do it. Nobody likes crashing, slow, or hard to maintain apps.
• Confidence is the feeling my clients have about working with me and my team. I want them to feel excited about what we’re creating. I want them to sleep soundly at night knowing that I got this and they’re in great hands.

4 Levels of Software Projects

We can use these outcomes to group projects into 4 general levels.

At the bottom is what I call the Nightmare Project. We’ve all been in one of these, or at least heard about one.

• The impact of this project is negative, so you’re worse off than before. You make less money back than you spent on the app.
• The quality is sloppy, and everyone can see it.
• You feel like you’re running blind.

The next level up is the Break-even Project.

• Here, the impact is negligible, which makes you wonder why you did the project at all. 
• The quality is decent.
• The team is confused: “We spent all this time building this thing, but the result is meh. Doing nothing would’ve gotten us the same result.”

With the right guidance, you can actually execute great projects, but these tend to be a lot of Hard Work.

• The impact is there, but it’s incremental (e.g. 10% improvement).
• Quality is great.
• You’re confident that you’re on the right track, but you’re slow.

Most people settle here. The myth that keeps them stuck is that this is good enough, and good enough will have to do. The truth is that it’s only good enough until someone else beats you. If you commit to excellence, your project can be a Dream Project.

• The impact is exponential.
• The quality is world-class.
• You feel absolutely confident that you’re working on the right thing with the right people. You’ve anticipated and de-risked the project before pouring money into it, and you feel that you can handle anything unexpected that the world throws at you.

I only want to do Dream Projects. And I have to be honest: I’m not a magical unicorn that turns every project into gold. I still mess up, but I find that this process maximizes my chances for success and failures tend to be inconveniences rather than catastrophes.

Core Principles

Protection

In Getting Everything You Can Out of All You've Got, Jay Abraham makes a distinction between customers and clients. A customer is someone who purchases a commodity or service. A client is someone under the protection of another. I work with clients.

My responsibility is to get my clients the most for their money. That means finding better, faster, cheaper ways to solve their problems, even if that means not taking their money. That means guiding them. That means persuading them not to do projects that will have negligible or negative impact.

Alignment

I want to work in alignment. What’s good for my clients should be good for me, and for my team. I want to help my clients succeed, because then they hire us for more projects, and make more referrals. I get to spend more time doing what I love – solving interesting problems – instead of selling. Everyone is happy.

Long-term Focus

The two principles above only work if you focus on the long-term. Talking someone out of a project they’re willing to do now hurts me financially in the short run, but in the long run it builds a great relationship that pays off for the both of us.

Strong Opinions, Weakly Held

I’m opinionated but not stubborn. My job is to advise my clients on the best course of action, but still execute if they want to take another path.

Understand the Ends

Clients tend to prescribe means instead of ends. In other words, they tend to prescribe solutions, rather than explain problems. My job is to understand the problems and ensure that we’re solving them with the best solutions.

Lead Up

I believe that leadership needs to happen up the chain as well. To serve my clients, it’s my responsibility to do things in a way that achieves the outcomes we want. For example:

• It’s not the client’s job to write up what they want and send it over; it’s my job to get what I need out of them by asking questions.
• The client shouldn’t have to ask for updates because we should run the project in a way that keeps them informed.

Avoid blaming the client (or anyone for that matter). You choose who you work with, so if you enter into an engagement that’s not 

I see lots of people blame things on the client, and I think that's misguided. I can choose who I work with, so it's my responsibility to choose the right clients and set the engagement up in a way that works.

Phase 0 - Vetting

During my first call with a client, I try to answer these questions:

1. Is it a problem worth solving that will make an impact?
2. Are we the best people to solve it?
3. Can we make this a dream project?

If the answer is “no” to any of these, I politely decline or see if there’s something else we can help with. If it’s all “yes”, I propose we do Roadmapping to scope it out.

Phase 1 - Roadmapping

Roadmapping is my way of setting a project up for success. The goals are:

• Get clear on where we’re going.
• Find the best route to get there.
• De-risk the project.

This also helps for our clients to gain confidence that we’re the right fit for the job. Choosing an agency is hard, even if you have good recommendations. We aim to make the process easier with this small engagement so that they can work with us and then make a decision about the full project.

Agile Planning

People usually fall on a spectrum ranging from no planning to rigid planning.

The extremes are troublesome. Not planning leads to confusion as to where you go and how what you’re doing aligns with your goals. Rigid planning locks in the plan at the beginning and prevents you from being responsive to change and finding better ways to do things throughout the project.

You want to be somewhere in the middle of this spectrum: Plan just enough to minimize risk and set a project up for success while remaining responsive to change and new information so you can course-correct. Anticipate what you can, and create a process that lets you adapt to the things you can’t predict.

Don’t fall into the trap of the Titanic. They failed to anticipate that an iceberg could sink it and that lifeboats would be necessary, and they were not adaptive to maneuver when they saw the iceberg.

If you fail, you should be able to say “We did our best and really couldn’t have seen this coming.” rather than “I wish we wouldn’t have been so arrogant and spent a few more hours working through different scenarios.”

Impact First

A common mistake is to focus on features rather than outcomes. It’s one thing to build a list of features. Building an app that generates a specific outcome like $100k in profit in the first 3 months is an entirely different project.

The key is to focus on the impact you want to make and work backwards from there to determine what the features are.

Painting a Picture

Imagine what the world looks like when you’re app is done and write it down. Be specific. Share it with the entire team. Refer to it throughout the entire project to stay on track.

This is a simple yet powerful exercise that aligns the team and gives them the autonomy to make their own decisions because they know where they’re going.

Getting Concrete

The rest of the process is going from vague to concrete and learning as much as possible along the way.

People-centric

Software is built for people. Don’t fall into the trap of catering to entities, e.g. “Fortune 500 companies”. Companies don’t press buttons, people do. Understand people’s needs, wants, and desires and whether they actually want what you’re building.

User Flows

Start with the very first encounter someone has with your product and list every individual step they take on their path to have a gratifying experience.

A simplified example:

List everything that people can do and link it together.

Make things concrete even if you’re guessing. Getting specific reveals assumptions that need to be discussed and validated.

Get Inspired

Study other apps to get inspired and model the best user experiences. I like to look at this as a LEGO set: Collect the best blocks from around the web, and assemble them in creative ways to build what you want. Your job is the assembly, not creating the blocks.

Scenarios

List all scenarios, not just the critical path. For example, what happens if someone's credit card expires after the first charge?

The combination of these scenarios is where the complexity, cost, and scope creep come from. Laying everything out at the beginning lets us have a conversation about what we need and don’t need and prevents us from getting blindsided later on.

User Stories

The actions in the user flow become user stories, which are the features of your app. They form the product backlog, which is the list of what you want to build.

Focus on Value

Write stories in a manner that focuses on providing value to the user rather than on how developers are going to build things. Users don’t care about components, they care about outcomes.

Say you’re building a quiz app that lets people take assessments. Instead of a story Build scoring system, it should be As a student, I want to take an assessment and immediately see my results, so that I can tell how well I did on the test. The scoring system is part of that story, but it’s not valuable unless someone can see the results.

The value of each story should be obvious, so that you can prioritize them at a glance.

The Pareto Principle (80/20 rule) applies here, as well: 20% of the features are going to provide 80% of the value. The art is in figuring out which 20% and focusing on those.

Wireframes & Prototypes

I wireframe and build clickable prototypes in Figma to make things even more concrete, so that everyone understands how the app is going to work.

The prototype allows us to link screens together and navigate through the wireframes as if it was an app. Inevitably this brings up things that we’ve missed and we can have a conversation about whether to include them or deliberately exclude them.

Most importantly, it gives clients the confidence that we’re on the same page about what we’re going to build.

Validate

Throughout this process, I encourage my clients to continue doing customer development and follow the Lean Startup process to ensure that we’re building the right thing. The wireframes & prototypes are powerful tools to guide those conversations and refine the scope. We want to learn as much as possible during this phase, because iterating on wireframes is cheap compared to code.

Choosing Platforms & Technologies

We choose which technologies we’re going to use to build the app. This can be a decision between web or mobile (or both), whether to focus on iOS or Android, build a hybrid app or native app, etc.

For ecommerce projects, the conversation is mostly about which platforms to use, whether it’s Shopify, a custom app built on Stripe, etc.

Technical Exporation

When we need to integrate with 3rd party apps or APIs, we do a technical exploration to ensure that the integration is going to work.

Compiling Perspectives

Each of the documents we create is an abstraction of the app from a different perspective. Keep them simple rather than cramming every level of detail in. To re-use the house analogy, the customer is going to be more interested in what the house looks like, and they wouldn’t get much from an architectural drawing if it showed the entire structure including the plumbing.

Format & Timeline

For the typical project we do, this process takes 3-6 weeks, though it can be faster depending on the complexity of the project. It’s collaborative: I meet with my clients 2-3 times per week over Zoom. 

Estimate & Prioritize

I bring in 2 developers to estimate the backlog. Estimating allows us to determine the build cost, uncover more assumptions, and prioritize the features. Then we typically iterate on the plan 1-2 times before we deliver the execution plan.

Phase 2 - Building

Once we know what we're building and how, getting it done is actually easy.

Keep Planning, Learning and Validating

Just because we’re done with Roadmapping doesn’t mean we’re done planning. We keep iterating on the plan and taking new information into account. Most importantly, we strive to validate that we’re building the right thing with real customers along the way.

Team

The typical team is a designer, two developers, and a tester.

Small teams move faster. Communication overhead grows exponentially with every additional team member.

I hire crafts(wo)men: Experts who’re passionate about their craft and do amazing work without being told how to do it. I find interesting problems to solve, create an environment where they can strive, and get out of their way.

For the type of work we do, T-shaped people are the best fit. They have deep expertise in one area, and broad expertise in other related areas. For example, an expert back-end developer who’s great at front-end. Or a mobile-developer who does back-end work as well.

This keeps the teams smaller, speeds up the projects because one person can do all the work related to a feature (e.g. the mobile app and the server-side API), gives us more flexibility with staffing, and avoids the project grinding to a halt when someone takes time off.

Testing

We do two kinds of testing.

1. Automated tests speed up development and improve reliability.
2. Exploratory testing by a real human to verify that everything works as expected, and proactively try to break the app to find issues before customers find them in production.

Speed

I’m concerned with 3 types of speed:

Performance measures how fast users can do things in the app. No one wishes an app to be slower. However, you need to consider how much to spend on performance as compared to building something else.

Development Speed measures how long it takes to build an app or its components. It depends on the developers and tools they choose.

Building something custom takes longer than assembling an app out of 3rd party components. The art in building products is determining which tool to use, and whether to build the feature at all. If you want a CSV importer, the options are:

1. Write it yourself. This could take a week or more.
2. Use a tool like flatfile.io. This can take a few hours.

Or, you figure out that early adopters can live without CSV import altogether.

Developers need to be skilled at three things:

1. Finding the right tools.
2. Staying on top of technologies and keeping track of what can be useful at some point in the future. I found flatfile.io because I check ProductHunt every day and log products that could be useful.
3. Leading the conversation about the tradeoffs between building and assembling. at finding the right tools and leading the conversation about the tradeoffs between building and assembling. 

The languages and frameworks you use are another factor. Adopting new technologies early means you have to write a lot of things from scratch whereas an established framework provides building blocks others have created that you can leverage.

Shipping Speed is how fast you can get your app out into the world. We bite small and chew fast. A common mistake is waiting to complete everything before you release software to customers. That’s wasteful, because the first feature you build can sit around being done while it waits for 3 months for everything else to be done. In this case you’re pushing learning off 3 months.

Make Progress Obvious

We run projects in a way that shows our work and makes progress obvious. We build features in small chunks that clients can use on a daily basis, so that they can always gauge how a project is going, especially when they’re non-technical.

Modern, Proven Technologies

We use modern yet proven technologies.

Old tech makes things harder than they need to be. Hiring may be easy, but I’m skeptical of developers who haven’t learnt new tools in the last 10 years. Learning new things is integral to solving problems, so it’s a red flag when someone has stopped leveling up their skills.

Shiny new tools don’t have developed ecosystems, so you often have to reinvent the wheel.

The middleground are these modern and proven technologies. Plus, you find the best developers in that area because they demonstrate the ability to learn new things and the wisdom to choose the right tools for the job.

We also strive for open-source tools because they have larger communities, more contributors working on making it awesome, and provide the flexibility to adapt them ourselves.

Flexible Agreements

Our agreements are flexible, because we value being adaptive to change. I don’t want to lock anyone into working with us if something changed in their business and it doesn’t make sense anymore.

Phase 3 - Maintenance

By the time we wrap up development, we want the app to be so well-tested that we don’t have to constantly jump in and fix things. Maintenance is more about the occasional upgrades to the dev environment and should be minimal. We set up a maintenance agreement to ensure someone is available for these things.