The Right Way

Some Thoughts

These days, everyone is more and more interested in building an app, from the big dogs at Apple, Facebook, and Amazon, to your local mom and pop coffee shop. As luck may have it, you may be considering building your very own app to solve that one problem that’s been bugging you for years and you’re finally sick of it; or for that unicorn idea you have that everyone needs, they don’t know it yet. If you’re not a technical founder, and definitely if you are, this guide is for you. Of course, this approach is not a one-size-fits-all solution, and the goal is to find what works for your business as it grows and changes, but starting here will give you an excellent foundation to avoid getting lost in the sauce.

Step 1: Don’t!

If your first instinct is to research the best programming languages, architecture paradigms, and cloud infrastructure best practices, my advice is don’t. I know what you’re thinking, “How am I supposed to build an app if I can’t build the app?” and I would like to caution you not to give in to the inspiring but misleading quote from the field of dreams. From a person who learned everything about full-stack development I could to build my first app, if you’re interested in creating a business around software, I promise you there's an easier way to get to your first customers. If you’re interested in software development as a career path, by all means, go ahead. It’s not a waste to go the whole 9 yards (sorry to mix my sports metaphors) and become a software engineer; I ended up starting Birdwell Solutions through to my experience, where I help startups build apps every day, but it's not the fastest path to your dream app business by a long shot. As a business owner, you have more significant problems than debugging and picking architecture patterns. Captain Picard didn’t fix the warp drive himself or beam down with every away team. Your goals should be on the overall vision and the success of your app-based service rather than performing its specific implementation, which will come as you work out your process.

Step 2: Get Feedback

Before you start putting pen to paper and designing or looking for software developers to build your prototype, reach out to your network and ask questions. You might be surprised where your once-in-a-lifetime idea diverges from your ideal client’s actual needs. You don’t want to get to the point in your project where you realize you’ve completely misjudged what your customers want or if they even exist at all. Still, no matter how you get it, feedback is more important to you than any developer or programming language right now. There are quite a few ways to get this feedback, from customer surveys to in-person interviews to Facebook polls. Once you’ve aligned your assumptions with the responses you’re starting to see, you’re ready to get down to the building.

Step 3: Build a Prototype.

Once you’ve confirmed that there’s a need for your idea and you have a clear vision of your goal, it's time to start bringing your idea to life. Rather than shooting for the moon and landing among the stars, start small with a prototype rocket and begin to understand why it keeps exploding first before investing in the full-scale model. There are various ways to do this, from a functional design to performing the business logic by hand, but only you will know what works best for your business and current situation. I’ve outlined methods in what one could consider an order of approach, but in all honesty, all or one of these methods can be used repeatedly throughout the startup process as you start to add business needs to your tool belt.

Step 3a: Low-Tech

The goal of a low-tech solution is to focus entirely on the process, not the tooling that makes it happen. This solution might be more extreme than others and seem counterintuitive, especially with all the shiny tools out there that can speed up your process. Still, it can provide some serious return on your investment by allowing you to focus almost entirely on understanding the problem before trying to solve it. Trying to run your business by hand before you start designing an app and spending time comparing quotes from contractors can save you a lot of headaches and keep you from getting lost in the weeds. If you’re building the next big babysitting app, for example, maybe start running a local operation with a few trusted friends and see where your specific pain points are using just a pen and paper and your phones. As you start to flush out the idea in analog, you can move your processes to digital solutions such as a low-code website.

Step 3b: No-Code

No-code is another strategy that doesn’t involve building the product itself as a placeholder solution that gets the idea across. This approach focuses on using 3rd party tools like Airtable and Mailchimp to get a more concrete view of digital solutions to real-world problems. This prototyping method can be a great precursor to your entire product because you’re able to hammer out the kinks in your system and start going digital, even as you’re bringing in users and potentially some serious revenue. Now is also a great time to start looking into tools like Figma to help you and your users visualize that end-game product that may or may not use custom code.

Step 3c: Low-Code

Low code is a method that has started to take the development world by storm in recent years. If you've ever used sites like Wix, Squarespace, or Bubble, you’ve already used low-code. These tools are beneficial when building your prototype because they come with many solutions right out of the box. It took me more than a month to figure out how to do a secure login feature for the first time (from scratch), and I’ve improved it every time I’ve built one for clients. If you don’t want to spend time figuring out the basics like that and want to focus on the “meat and potatoes” of your app, low code is here to save you time and energy. If you have a business already, or you’ve been doing intense market research and have tons of feedback, and you know your process and pain points like the back of your hand, then, by all means, start looking into a building that low code solution. Like the above, it's a great way to gain users and revenue across all devices without investing thousands of dollars into a custom application.

Step 4: Get MORE Feedback

Once you’ve got your prototype in hand and an audience to put it in front of, it's time to start signing up customers ASAP. Whether it's friends and family, or the fan base you’ve been cultivating over the last three steps, make sure you get people using your app, and more importantly, start getting that feedback! It's still your most valuable resource, but now, rather than the idea itself, you’re focusing on your implementation. No matter how confident you had it right the first time, you can always add more information to the arsenal and get more in tune with your target customers. If you’re still not quite finding that perfect product-market fit, maybe it's time to consider pivoting your business based on the feedback you’re getting. While you’re in this phase, it may be beneficial to keep access to your service limited in a closed beta to target specific goals, but the more people you can get feedback from, the more information you have at your disposal. Whether your beta is open or closed, make sure there are multiple ways to gather information from your users directly or otherwise.

Step 5: Analyze Your Results

If you’ve started to get a reasonable amount of traffic, or you’ve conducted some user interviews, it's time to put it all together and start finding the value in the numbers. If you notice that many of your users see a specific page as challenging, note that for the next step. Be careful not to overfit your analysis to any particular user or try to find a result to match your assumption. It can be tempting to try to build every feature that every user suggests but stay vigilant. Don’t forget to read and act on the negative feedback, either. It can be daunting to receive a negative review, and if someone’s passionate in a good way its easier much more palatable. However, if a user is willing to take the time to fill out a response form, take that as a good sign and make sure the next person who comes along doesn’t have the same negative experience. As you start to grow, you may want to look into specific methods for analyzing and acting on that data, which we’ll cover in another article, but for now, focus on understanding information from your new users.

Step 6: Improve Your Product

Just as getting started on this idea, you don’t want to get too caught up in your thoughts. Armed with feedback on specific pain points for your app’s implementation, you should start seeing places where you can improve your system. If you noticed half of your users bounce from a particular page, maybe look at the feedback from some of them and devise a call to action that makes more sense, or perhaps even go as far as to add a new feature if your data calls for it. Whatever your solution may be, ensure that you come to it through feedback and data rather than gut feelings or personal preferences.

Step 7: Do it again…and again. (Go back to step 4)

You’ve gotten feedback, analyzed it, and improved your product. It's time to do the whole cycle again. Building the next big thing doesn’t happen overnight, and as your user base grows, the various needs and challenges you have to overcome to keep them all satisfied. You may have misinterpreted your data and add the wrong improvements, or you may uncover an idea you hadn’t thought of before. Whether you and your customers have your goals perfectly aligned, or you’re still trying to find that perfect product-market fit, the faster you can iterate through this loop, the quicker you can provide the experience your users are seeking.

Step 8: Expand on Your Idea

Eventually, you'll reach a point where new ideas and features are becoming more and more challenging to implement using your current solution. Maybe you released your service to mass audiences, and that prototype can’t keep up with demand. Low / No-Code solutions are a jack of all trades and a master of none, and when your business needs begin to outgrow them, it's time to look elsewhere. Maybe you release a mobile application for your users on the go; perhaps it's real-time updates to that news feed or even an entirely new line of business that you discovered while experimenting. Whatever it is, it may be time to start looking for that technical founder or contractor to help you break the low-code box. Many of the products on the market have full support for custom code, so don’t throw your current application in the trash just yet and, whenever possible, develop as little as you need to make it to the next level. We’ll cover finding a developer to work with you through this process and beyond in a later article. At Birdwell, we focus heavily on this positive feedback loop through the entire development lifecycle. Whether you’re just starting your first wireframe or developing custom extensions for your low-code application, we’re here to make it work. Want to learn more? Schedule a free discovery today!

How To Build Your First App was originally published in Birdwell Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hint, NONE of them are the Covid-19 vaccine

1. Your Smartwatch / Fitness Tracker

If you’re a member of the cult of Apple, you’re probably already too far gone at this point to care, but yes, your apple watch, the thing that tracks your sleep cycle, location, and heartbeat is tracking you. If that wasn’t your goal I’m not sure why you opted into buying a smartwatch in the first place. From ordering an Uber to live streaming your baby monitor, these devices were built with one purpose, to keep you as connected to the internet (and its denizens) as possible.

2. Your TV

If you think you’re safe watching TV, you've got another thing coming. Even before the mass adoption of smart TVs bringing Netflix and the like to home screens worldwide, Cable companies (and their strategic partners) used a system called ACR or Automatic Content recognition to try to figure out what's on your screen any more time you’re watching it. An article by the consumer reports revealed data was being used privately by companies and the practice wasn’t widely known until one of the big cable companies ( cough cough, Vizio ) got thrown under the bus for collecting information about users without their consent. This was back in 2015, and needless to say, our TVs have only gotten more sophisticated since then.

3. Your car

It's not just Tesla that’s going high-tech. Even if your car doesn’t have an onboard navigation system or the fanciest computer, you’re not exempt from being tracked. According to an investigation by the Washington Post, if you own a modern vehicle, you're generating up to 25Gb per hour of analytical data that you’re sending straight back to your automaker, without regulation.

4. Your friends and coworkers

Have you ever made a phone call to your mom, emailed your boss, or been in a picture taken with a smartphone? If you have, you’ve been “tracked”. No matter how safe you think you’re being, unless you’re a world-class cybersecurity expert, and a hermit, the odds of you showing up in someone’s news feed, tagged in a photo, or having your conversations stored by a third party have become near 100%. The pandemic bringing life, in general, more online than ever doesn’t help.

5. Your fridge

Yes, really, even your fridge will start to track you at this point. At $6k a pop, I would hope it has wifi, but with that, you bring all sorts of fun new visitors to the family fridge like your ISP and any other software providers that may have struck a deal with your fridge manufacturer. If you’re one of the proud few whose fridge tells them whether their milk is going bad, keep in mind, you’re not the only one getting the memo.

Final Thoughts

If you’re using any of these devices, don’t fret too much about tracking because at least where I’m writing this article from, there’s very little you can do about it. Short of moving to the woods and living off-grid which, let's be honest most of you aren’t willing to do, or another planet, if you own a smart device, or honestly even some fish monitors at this point, you’re connecting yourself to the net and all the peeping eyes it may bring. Don’t throw caution to the wind but of course, proceed with caution when adding any “smart ” anything to your arsenal. Last and certainly not least, unless you’re medically exempt, please for the love of god get your vaccines.

Check us out!

Like this article? Interested in learning more about tracking and how you can responsibly add it to your product? Check out our team Birdwell Solutions and schedule a free discovery today!

5 everyday things that track you was originally published in Birdwell Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yes, everything

Why Use Docker At All?

Why not just run the software locally?

Long ago, before the event-driven serverless cloud apps of yore, developers were tasked with producing specific binaries for each system that their software was intended to run on. The configuration of these apps was dependent on the host system. If you have one machine or a relatively small network that you’re exposing to the public, maybe it's simple to run services locally and manually configure that in-house solution. Still, as a system grows and adds more moving parts, this stops being the case. Naturally, this problem would compound exponentially when a company has thousands of developers working on hundreds of services running on countless machines utilizing dozens of different languages and frameworks (whew…). If you’re familiar with the story of Babel in the bible, you get the picture. One bug could lead to mass confusion and hysteria, or even total system failure when configurations would vary from system to system. Once developers began working on massive networks of machines running on different devices and networks worldwide, developers and their companies needed a better solution.

The Reign Of Virtual Machines

Many solutions arose, one of which, called a virtual machine, gave the software or simulated OS or environment to run on, which significantly reduced the strain on developers to configure the environment they are working with. Languages such as Java and Kotlin harness the power of the JVM or Java Virtual Machine, enabling developers to “write once run anywhere,” which is really nice if you work in one of the languages that support the JVM. If you want to run something outside of that, such as C or Ruby, you’re kind of out of luck unless you do it the old-fashioned way and compile to a specific platform binary that matches the virtual machine you are using. Sure, you could use a ported language like JRuby to compile Ruby code into JVM compatible binaries, but that still leaves the environment setup and orchestration problem.

What The Heck Is A Container, Anyway?

Containers are the next logical step after virtual machines. They package the application with its dependencies into a portable, secure, and lightweight form that, if run on one supported device, can be run the same way on any other device. Not only is the environment set up as a part of the build process, but docker containers may run scripts, commands, and other such things to set the environment up just right the first time, every time. These “containers” are “orchestrated” or managed by a “daemon” or worker that is responsible for the lifecycle of each of the docker applications running on the host system.

Like virtual machines, developers may run multiple docker containers in unison on one host machine, each with its own packaged environment. Rather than having multiple potentially different operating systems running virtually with environments that developers must set up beforehand to run the application correctly, the prepackaged apps run on the Docker engine by utilizing special config files or Dockerfiles.

Why We Use Docker

“But, It worked on my computer!”

Birdwell Solutions is a software development agency that specializes in working with entrepreneurs and startups through the lean startup experience, so we’ve used Docker on anything from database clusters to full-stack web apps to real-time location-based service-on-demand applications. When we’re trying to coordinate with multiple developers to push updates to our clients rapidly and frequently, we don’t have time to ask, “will it work on this device?”, we need to be confident that it will work the same way, every time. When we remove the question of infrastructure and configuration from the equation, we get to focus on what we do best, building apps for our clients.

Options, Options, Options

If we want to run a somewhat complex build sequence or have multiple release streams, it may be important to set up our environment differently, depending on the needs. In the spirit of reducing work that isn’t focused on adding value for our clients, we’re able to spin up different versions of their applications in minutes by writing Dockerfiles instead of manually configuring server environments repeatedly. If we need a demo version of an application that deploys separately from the rest of the project, we can spin that up in a matter of minutes rather than hours.

Less Is More

We use Google Cloud Platform as our primary solution for cloud services. Since Docker runs pretty much everywhere, it also integrates well with most cloud providers. Using services like Cloud Build and Cloud Run, Docker lets us automate our build lifecycle all the way from pushing to Github to launching and load balancing active services. We will be writing further articles on how we use docker to automate our dev-ops process to do more for less, but every major platform has first-class support for Docker containers. Taking compilation and deployment out of the list of concerns increases our iteration speed and, thus, the value we can provide our clients.

Do we really run everything in a container?

Unless there’s a reason not to, Docker is a standard on every part of every project we work on. If it runs on Linux or Windows, which is just about everything we build (except mobile apps, which we’ll get to) at this point, we run it in a container. This includes everything from web clients to web servers to caches to databases. Databases are stateful and can be tedious to run locally, so we recommend managed services like Cloud SQL or MongoDB Atlas. Still, it is entirely possible to run these systems at scale in a container, which I will explain in a future article.

Some Limitations

There are certain use cases where it may not make sense to utilize containerization, such as when you are developing platform-specific software or are developing for an OS that is not Windows or Linux, such as a Mac OS app, but since most of the languages in the world can run on those two OSses, when in doubt, we throw it in a container and can then run it on Mac, Windows, Linux, Raspberry Pi, etc. Mobile applications are an entire device category where we don’t implement Docker in every process. Since the operating system of choice already manages the deployment and orchestration of mobile apps, we are unable. We don’t really find it necessary to put these systems into a Docker container. Birdwell Solutions prefers cross-platform frameworks like React Native and Xamarin, which compile to platform-specific binaries anyway and are deployed through app stores, yet another article. Besides the mobile app itself, the whole system is still wrapped in containers.

Why We Run Everything In Docker was originally published in Birdwell Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.