If you’re a Star Trek fan, you already know where this is going.
“I’m a doctor, not an engineer!” screamed Dr. Leonard McCoy in the original series of Star Trek.
That iconic phrase spawned many repeats and for good reason. It is the expression of being called to do something that is outside of your expertise to the extent that you’re surprised if any solution actually accomplishes a fraction of its intended purpose.
This “I’m a doctor, not a…” blank meme resonates with almost everyone.
Within this mindset I write this article; to help anyone who’s ever felt to say, “Dang it Jim. I’m a CEO, not a web developer!”
When I said this phrase myself before I became a web developer, it was more like, “Dang it Jeff, I’m an entrepreneur, not a software engineer!”
I was a year into my post-undergrad job and I started working nights and weekends on an idea to change the way we buy products. I needed technical help and was enchanted by the notion of getting it for a fraction of the cost overseas. Jeff, the account manager for the outsourcing firm (who’s name has been changed for privacy), sent me a solution that was twice as expensive as budgeted and a fourth of the quality I expected; but, it performed, and looking back, that is all I could expect when operating so far outside of my expertise.
I’ve spent the last several years building Buink to help people like me. As I think about Buink’s happiest clients, they’re the Entrepreneur/CEO/Founder/Business Person/Marketer that can’t afford a project failure by working too far outside of their expertise.
In other words, our goal is to help you avoid screaming “Dang it!” in the following ways.
Lower Risk
I heard these exact words from a client last month, “I wish we had found you before we spent 100 thousand dollars on other developers.”
The amount of money that is wasted on poor quality, buggy, ineffective code is staggering. If you’re not careful, you can blow 10 grand in a blink and have almost nothing to show for it.
Over the past 3 years, we’ve built processes and paradigms that ensure you’ll get value from every dollar you spend on development. In fact, we stand behind our code in the form of discounts if we fail to deliver the value our clients have come to expect.
Better Solutions
We base our solutions on tried and true principles of web development. We’ve written articles on these principles in the past, but some examples include code duplication is bad, simple is better, foundation is important, servers are cheaper then humans, etc.
These principles help us find more intelligent solutions.
One recent example of this was when our client wanted to roll out an IOS app. As we built out the plan, we had the familiar uneasy feeling of violating the code duplication principle when trying to keep everything in sync across the web and IOS.
On other projects, we had used a cross-platform technology that allowed teams to maintain one front-end code base and use it across the web, IOS, and Android. Only recently, these technologies passed the usage threshold proving they’re robust enough for consideration, the problem is that you can’t add them to existing projects easily.
Wouldn’t it be great if we could find some open source software to take our current front-end and build it for IOS? This would not only help us avoid code duplication but also drastically reduce the cost of the new app.
Our search began and ended surprisingly quickly. We found a fledgling open source project that was coincidentally maintained by the makers of the cross-platform technology mentioned previously.
Despite its newness, the software paid off handsomely for our client. We ended up being able to add this technology to our codebase, spin up an IOS app, and access native functionality like in-app purchases as well as password storage via IOS keychain.
This big win was only made possible by our principle based approach.
Pre-written Code
A good portion of the online asset you want to build has probably been built before. Things like user authentication, database connections, routing, and templating are used almost ubiquitously across the web and should not need to be re-invented for every project.
So, to lower your overall cost, we leverage as many open source technologies as we can. They lower the learning curve for adding new developers to a project. They make it easier for us to communicate standards for writing new code. They also provide a solid foundation that we use to add your custom business logic.
We’re very proud of the technologies we recommend, you can see most of them on our services page.
In addition to those technologies, we also have proprietary boilerplate code that we use to further lower the cost of your project. We’ve found that these open source technologies can be improved by adding another layer of code to make them work in tandem better and for other common requirements.
These boilerplate helpers are built on top of existing open source projects and are written with the highest standards. Similar to the open source technologies, they also reduce the time it takes to start writing your custom logic. In addition, they’re included free of charge when starting a new project with us.
No Black Box
I am a strong believer in transparency. You’ll find this belief sprinkled through our guiding principles, our operations, our contracts, etc.
When working with us, you have access to the code, the communication systems, the project management system, everything. You can contact our developers directly and immediately if needed.
From the very beginning of Buink, I’ve been trying to open the web development box and shed some light on how things work. I’ve written articles on what a website costs, ways to lower that cost, how to make offshoring work, why our contacts are the way they are, and some common ways that projects go wrong.
Even if you’ve been part of a development project in the past, these articles can help you asses whether your values align with ours and help you understand how we operate. My main goal is to avoid unhappy customers who learn these things part way through their first project.
Truth is, however, no matter how much you read, you’re likely still operating outside of your expertise and you could benefit from an expert like us on your team.
Business Mindset
We speak your language. We look at everything from a business perspective. You’ll get a good sense of why we do that in our article about striving to be code butlers.
Let me share an example of this. I have an ongoing client who had it written in our original contract that I was not to contact her directly but to work with and report directly to her lead developer.
I thought that was a bit strange, but I figured she’d probably had developers in the past who asked pointless questions and/or didn’t respect her time and needs.
Fast-forward two year, we’ve helped her build out a system to automate her quickly-growing business. She and I also have a bi-weekly meeting and her’s is one of our longest ongoing projects.
I attribute her change in behavior to our ability to understand her business needs and how she needs us to work with her.
Control Your Spend
On a typical project with us, all change requests are approved by you before they’re started, they’re approved again by you once you see them in a testing environment, and finally they’re approved again once released to a production environment.
There is no black box. With every deliverable review, we note the total time billed for any given task. We also send you detailed weekly reports with quick-to-skim summaries so you know exactly how your money is spent down to the second of billable time.
Solid Code
In addition to your review, all code changes are reviewed by a lead developer to ensure code quality and value. We’re checking for adherence to our guiding principles and other industry best practices. We’re also looking for security flaws and potential bugs.
The result of our review processes are more solid, less buggy, more valuable code.
Better Designs
We’ve worked with many great designers over the years and we’ve still never met one whose designs can’t be improved by doing technical reviews during the design phase.
We do offer design as a service, but if you already have a favorite designer, you can still involve us in your project to offer technical direction and feedback.
Diversify Your Team
Which team is more likely to succeed: two in-house developers or one in-house developer and one outside developer consultant?
You can probably guess we’d propose the latter.
In-house developers are awesome if you have enough work to support them. They’re sometimes more affordable then contractors (although not by as much as you might think). You have more control over them (in case you’d like to flex your tyrannical muscles). And let’s face it, hiring “in-house” has been the status quo for years (if you care about that kind of thing).
You probably sensed some sarcasm, but in-house developers have some challenges of which you may not be aware:
- They’re often pigeonholed into outdated technologies for years so their experience may not be equal to that of a contractor with the same years but who is constantly working on more modern technologies.
- They often move slower then contractors preferring to be comfortable rather then challenged, flexible, and value focused.
- They sometimes write code in a way that makes them indispensable rather then writing in a way that anyone can pickup where they left off.
Please excuse the general stereotypes, my main point is that hiring “only in-house” isn’t the only strategy and likely isn’t the best strategy. Don’t put all your eggs in one basket when it comes to building your team.
We do understand that bringing developers in-house can reduce the sticker shock of building a website. If you have enough work to support multiple ongoing developers then bringing someone in-house may be smart.
We’d still offer our services as a member of the team or to setup the project, setup the architecture, review code, or manage the project.
