We’ve only begun to scratch the surface of what is possible with technology. Internet opportunities aren’t like a gold rush, where the wealth creation is limited by supply that is drying up, a more accurate metaphor is how electricity enabled ongoing innovation for more than 100 years.

This idea was first promoted by Jeff Bezos. If you haven’t heard of Jeff, then you’ve likely heard of his brain child, the largest internet company in the world: Amazon, the everything store.

In 2002, the company almost died. The dot-com bubble burst and investors wondered if the internet was just a fad. Amazon needed capital to meet the needs of insatiable customers, but their stock was down 90% and capital had dried up. They started losing executives hand over fist and the future of the company looked incredibly uncertain.

One of Bezos’ executives commented at the time that he couldn’t understand why Jeff was so calm when everything seemed like it was on fire.

Jeff knew something they didn’t and what he knew turned out to be true. He shared his secret on the TED stage in 2003. The internet isn’t a gold rush that makes some wealthy until the supply of gold dries up. The internet is a horizontal enabling layer, like electricity, that will lead to innovation for the next 100 years.

The light bulb was just electricity’s first killer app, Bezos said, which helped wire America. Once electricity was in every home, it ushered in the golden age of appliances, a 50 year period of innovation. It startled with the iron, the fan, the vacuum, the washing machine, the toaster, the robot, and it continues to be the foundation for modern life.

As you know, electricity has become so much a part of life that when it goes out, we still switch on the switch and wonder momentarily why the light didn’t go on. 

Was he right? Well, we’re now 17 years into the metaphor and it continues to hold. In fact, as mentioned, Amazon is now the largest internet company in the world.

At the end of his talk he shared an advertisement from Sears in 1917, “use your electricity for more than light.” That is still where we are with the internet. In the next 50 years we’ll see everything become dependent on the internet’s enabling layer.

What does that mean for you? That means if you don’t have a solid internet strategy about how your business is going to compete online, then you’re not thinking far enough ahead.

Whether you’ve started on your strategy or not, we have some tips that will help you succeed. These tips are a free gift to you.

Download our free Guide to Tech Projects for Non-technical Founders.

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.

Have you ever found there isn’t “an app for that?”

I hope you’re reading this because, like me, you increasingly see more and more opportunities where you could leverage the internet to solve business problems.

Opportunities like: 

• “Paper? You want me to fill this out on paper?” 
• “What if we could see real-time data on this project?”
• “Fax machine? Does anyone have those anymore?”
• “What if we used reputation and engagement to increase trust in this product?”
• “I wonder what we could do with crowdsourced data on this problem!”

We’ve only begun to scratch the surface of what is possible with technology. Internet opportunities aren’t like a gold rush, where the wealth creation is limited by supply that is drying up, a more accurate metaphor is what Jeff Bezos calls the electric metaphor for the internet where electricity enabled ongoing innovation.

So with all this opportunity, are you capitalizing on it? Maybe you don’t consider yourself technical enough? Maybe you’re a business person/marketer/leader not a coder, web developer, technologist.

No worries, I’ll share some tips and tricks that may help.

You don’t have to be a techie to take advantage of the technology run that is still going on. There are still many industries to disrupt and many opportunities to discover. Follow these tips and put them into practice and you’ll be able to enjoy the spoils as well.

We have some tips that will help you succeed. Follow these tips and put them into practice and you’ll be able to enjoy the spoils as well. These tips are a free gift to you.

Download our free Guide to Tech Projects for Non-technical Founders.

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.

I’m often in search of the perfect picture or graphic for a new site and I’ve compiled a decent list of sources over the years. I’m creating this page to make it easier for me to share these.

I’ve tried to list these options from most expensive to least.

Buink can help you unleash the power of the internet (via a website, web application, api, or mobile app) and help your business scale (via both technology and workforce) with superior quality code (readable, forward thinking, minimal, intelligent), at a competitive price (even in a global market), and in a transparent, honest way.

We’re code butlers and we both build and maintain web assets. Start scaling your business now.

Internet Power

We help you gain your own internet super powers, you may even need a cape.

Empower your customers to get to know you with a user friendly website. Improve or disrupt your industry with a new web application. Increase your productivity and get more insights from your business with a mobile app. Then level up by connecting them all into one seamless technology strategy.

In other words, use the power of the internet to scale any aspect of your work: marketing, operations, competitive advantage, etc.

Scalable Workforce

Employees don’t scale but your technical needs do.

What if you could scale your team like you can scale cloud servers? Our proprietary blend of people, technology, and process can help propel your project to greatness. Say that 10 times fast. 🙂

People Power

You need a new developer ASAP to meet a deadline on a marketing campaign? You need to drop two developers from your mobile app due to budget constraints? You need a developer for a couple months and then scale back to just maintenance mode? Buink can help!

Everything we do is optimized to help you scale your team to meet your deadlines and maximize your productivity. We have a constant flow of top talent and we stand behind our code value and quality. Whether you have an in-house team or have no technical expertise, we’re a valuable addition to any project.

Team Technology

It doesn’t matter how many people you add to your team if they take forever to get up to speed. We’re constantly reducing and improving on-boarding and we’ve come up with a notable solution that involves a mix of proprietary software and ubiquitous technology.

Software Solution

We can add a new developer to your project in under an hour with no training and have them running your code locally and diving in to make changes. This is shocking compared to the majority of projects that can take days or weeks to get a new developer adding value.

We accomplish this shocking feat using proprietary code and open source technology (Docker) where a new developer can run one build command, wait about 20 minutes, and then see the code base in action locally.

Widely Used Technology

Part of getting the most out of a new developer is finding one who already has experience in the technology you’re using. We’re very “choosie” when it comes to what languages, software, and packages we use and recommend.

Our current recommendations are both proven and powerful. Feel free to call and pick our brain about what you could use for your next project.

Team Process

You’d be surprised how often the bottle neck of scaling a team is bad process.

The jump from one developer to two is exponentially harder then from two to 5 which is exponentially harder then from 5 to 20. So why not start with a process that doesn’t change as your team scales?

This isn’t as easy as it sounds. How do you coordinate multiple developers through the development lifecycle, from idea to production? How do you keep multiple changes independent from each other so they don’t become blockers to other higher priority changes? How do you keep everyone moving and prevent wasted time? Oh, and how do you do all this without adding an obscene amount of overhead? Buink has found the answers.

We’ve already solved these problems and we can bring this mindset and processes to your team. We could also coach your team to make it easier for you to scale on your own.

Code Quality & Value

Here is where the rubber meets the road. If there is one topic that is constantly on our minds it is how do we deliver superior quality code at a price that is competitive with any other provider.

This isn’t easy, and it has taken us years to achieve, but we’re confident we can help you win, even in a global marketplace.

Code Quality

In the fishing pool of propositions, we are optimizing for quality. We ensure quality with our process of code review and our coding principles.

Code Quality Review

No code makes it to the internet without a review by a senior developer who is also an expert in our principle based coding practices.

Unlike a peer review structure, our lead developers are the single point of contact responsible for all code. This hedges against security flaws, technical debt, and unreadable spaghetti code. It also reduces the possibility of redundant or overly complex code.

Principle Based Coding

Principles help us know how to make trade-offs that inevitably arise when dealing with the reality of distilling complex business goals into simple, well-written code.

Readability

Our key insight here is that people are more expensive then servers; therefore, we optimize for readability rather then server efficiency. You’ll find this is surprisingly unique to our methodology, and yet very valuable.

Self-documented Code

Writing code in a way that makes external documentation obsolete not only makes code more readable, but also more maintainable and more robust. This principle alone saves thousands of dollars in maintenance, uncovers countless bugs before they make it to production, and helps us ensure the quality we demand.

Language Focused

Words are the tools we use to translate complex business goals into simple technological solutions. A vague, generic, or thoughtless word can lead to surprisingly large and costly miscommunications. This is why we put a huge emphasis with both clients and developers on the word tools that are right for the job.

Forward-thinking

If you’re like us, you’re looking to win in the long game. We don’t like carrying technical debt and we don’t shove things under the rug knowing that future developers will no doubt trip over it. Most of the time, we are those future developers, so we like to do things right the first time.

Code Organization

Where you put code is almost as important as how you write it. We fully embrace popular architectural patterns like MVC in addition to other wisdom around folder structure and business logic.

Code Value

Delivering superior value isn’t easy but our recipe for success is to monitor it, flatten the learning curve, and operate in an efficient way.

Value Discounts

When working with high dollar resources, you expect every billable minute to pack a valuable punch.

In addition to our quality reviews, we constantly monitor the value of code deliverables. If deliverables come in over our estimates, or if a task becomes risky in any way, we can flag it to not be billed till it is completed and fully reviewed. If we messed up, you’ll find a nice discount on your related invoice.

We put our money where our mouth is. When we break a project down into individual tasks, we’re quite good an knowing how long we’d expect a task to take and, by extension, how much it should cost.

Flattening The Curve

Our desire to lower the learning curve isn’t just a platitude, we use a combination of proprietary software and intelligent technology.

Curve Flattening Software

We’ve already mentioned our proprietary software under the Team Technology section above.

This software not only helps get developers up and running quick, but it also keeps the development server in sync across the whole team as well as all the way to production.

In practice, this means that a front-end developer doesn’t need to know how to build a server just to make a change and they don’t need the help of another team member to do it either. Server changes just happen magically and the front-end developer is back doing what they do best.

It also means that we’re less likely to see production only bugs which are costly and risky to fix. The server we use locally is identical to production so we catch bugs way before they risk affecting your live site.

Widely Used Technology

Part of lowering the learning curve is building with technologies that are widely used. Not only do we benefit our clients by choosing the best open source technologies but we also specialize in one of the most widely used and versatile languages in development: JavaScript. We’re also expert in another language that powers more server side software than any other language: PHP.

The adoption of these languages and the likelihood of their longevity means that there are more people that know them and who can jump into our projects more easily.

Efficient Operations

The total cost of a web asset doesn’t just include coding cost.

The coding life-cycle starts with an idea or business goal. That idea needs to be formalized into a task which is sent to a developer who makes code changes. The changes are sent to a lead developer for code review and testing on a quality assurance server. The lead sends the new feature to the client for testing and approval. We then deploy the feature to production where it can again be tested and closed by the client.

As you can see, the total cost of a feature is greatly affected by the efficiency of operation throughout the coding life-cycle. We use a special blend of third party and internal software to push tasks forward while reducing the amount of wasted time.

Transparency

We hear that we’re some of the most transparent in our industry and we love what we hear. We want you to know exactly how your project is going and how your money is spent; to that end, our communication and invoicing is an open book.

Open Book Communication

We not only recommend but encourage clients to be involved in the internal communication of our team. We give you access to our project management software, the code repository, our developers, and just about any other access you’d like.

Transparent Invoicing

You’ll never wonder what you’re paying for, we break it down and also summarize it like you’ve never seen.

We track billable time down to the second and we send this detail along with our invoices. We encourage developers to break each task down into sub-tasks to track our time with more granularity. This leads to better planning, more valuable code, more accurate time tracking, and more transparent billing.

Each person on your project also sends you a written summary of their efforts to help you get a quick overview if you don’t need to dive in to the detail.

Aligned Incentives

The clearest takeaway from a study of economics is the importance and power of incentives. Some of our business practices are unusual, but they’re all in place to keep our incentives aligned with yours in our goal to deliver high quality code.

Hourly contracts

We don’t play any games with price. We’re not trying to get rich off your project, and we’re also not wanting to loose money. We just love to code and we’ve found that charging hourly allows us to avoid picking favorites or promising things we can’t deliver.

We wrote a whole article about the flaws of fixed price bidding. Learn more about why we think hourly contracts are better for you.

Working with us is as easy as sending us a task and we send you back code. It is that simple. We’re a member of your team just like any other, with the added bonus of being able to flex up and down quickly depending on your needs.

Conclusion

This article isn’t a sales pitch, this is who we are, how we operate, and what we focus on. If you can see the wisdom in our paradigm, then I’m confident you’ll be just as happy as our past clients.

Check out our services or contact us for more specific ways we could start helping you today.

So, websites are expensive. What can be done to lower the price? Plugins? Packages? Open source?

I had a call with a potential client yesterday, we’ll call him Joe. Joe asked about a site that was essentially a mix between Yelp and Reddit for a niche market. He wanted a “quick quote” on something like that. Not having more than a one page description and a short conversation about his vision, I could see this was going nowhere fast.

I tried to explain the reality of web development and before we ended the call he said he was hoping to just customize plugins that were already written. I told him I’d look into it and quote him a lower price if we found any that would work, but truth is, that isn’t likely.

Joe is right, sometimes you can build a great technical solution cheaper when the following rare development event occurs:

1. Finding the perfect piece code already written
2. Finding it on the platform of your choice
3. Finding the perfect developer with…
4. Enough experience to leverage it for the long-term benefit of your company

Let’s loosely define packages as any code snippet that can be easily included in your code base to add functionality. This would include everything from jQuery plugins to Linux packages.

Packages have their place and I’d NEVER recommend writing code that has already been written. The problem is that most packages have two flaws, (1) they’re not written well, or (2) they don’t play nice with other code. So, we have to be thoughtful about the packages we use.

The rule of thumb I use to decide when to leverage a package is:

• Yes, if the functionality isn’t core for my business
• Yes, if the the functionality is ubiquitous (i.e. many if not all site needs code similar to this)
• Yes, if the package is widely used
• Yes, if the code is written well

I’d have to say yes 3-4 times to even consider it.

I have no doubt that we’d leverage several packages to reduce the cost of Joe’s website, but at first glance it seems unlikely that someone has built the Reddit/Yelp functionality that fits all the criteria mentioned above. For example, this functionality seems core to his business, and this functionality is not ubiquitous.

What is the worst that could happen? I’ve seen it time and time again, companies hack solutions together only to uncover hard to solve bugs and integration problems with existing and future features. In the end, most re-write their core functionality from scratch at great cost.

Packages paint you in a box, so you better really like the box before you get in.

You’re probably getting a sense for why I call it a rare development event.

The following Principles and Guidelines are outlined to help new contributors get up to speed quickly. The original title for this post was “New Contractor Training” and the purpose is still very similar.

Principles

Principles are fundamental propositions that can serve a foundation for a system of behavior. In other words, these principles will help you make decisions that will lead to your success at Buink, your success in our industry, and may even improve your success in life.

Although “what you do” while you’re billing time is important to Buink, even more important is “why you do” what you do. Use the following principles to help you decide why one decision may be better than others:

• Honesty/Transparency
• Efficiency
• Clarity (communication)
• Quality

Guidelines

Guidelines are examples and recommendations for ways to implement the principles.

Honesty/Transparency Guidelines

Easy Time Tracking

Time tracking at Buink should be easy if you’re doing it right. Just click the start button (as shown in the GIF below) and let the Toggl Chrome Extension do the rest. When you start a new sub-task, the previous one automatically ends, so you can focus on what is next and move efficiently between tasks.

Granular Time Tracking

To avoid and reduce mistakes in tracking time, we suggest that you continually note and consider what you’re billing for at any given moment. To make this easy, use checklists to create a plan for all substantial tasks. Items in the checklist are sub-tasks and you can easily track time against any sub-task. The checklist item should describe what you’re doing at any given moment.

Weekly Review

At the end of each week, you’ll get an email from us asking you to review your time and send a summary. The goal is to first, make sure there were no mistakes, and second, write a summary of what you did for each client. We like to be transparent with our clients, so they get a full breakdown of every time entry and your summary with their invoice.

Efficiency Guidelines

Card Priority

Trello boards have columns of cards called “lists” and each list has one or many cards in it. All cards on the top left are higher priority then the bottom right. So, you’d always want to work and communicate in order of priority. For example, if you had a card “In progress” and a team lead moved another card above it, you’d want to switch your efforts to the higher priority card.

Urgent Cards

Urgent cards should never be blocked. Whenever an urgent card is waiting on someone they need to be notified via chat. The most common way cards become blocked is waiting in review, so when this happens, you’d copy the link to the task and send it to the team lead via chat.

One Card At A Time

In a perfect world, you’d only be working on one card at a time. When you finish that card it would always be approved and you’d move on to the next card. You’d never start two cards at a time because it is impossible to work on two cards at one time and doing so could cause delays in the project.

Unfortunately, we don’t live in a perfect world. Sometimes cards get sent back for more changes or sometimes cards you’ve worked on become blocked waiting on communication or for other reasons. That said, we always want to strive for the perfect world.

Clarity (communication) Guidelines

Communication in Context

The most common place for communication is on the Trello card because the card is the official work order and we want to keep a record there of all requests, comments, and questions. That said, it doesn’t make sense to ask complex code related questions or detailed design related questions anywhere other then in the best context. So, if your comment is about code, ask it within a pull request (PR) and add the link on Trello. If your comment is about a design, ask it on the design and add a link on Trello.

You can see that the card becomes the hub for all communication. Even if your comment is urgent, you’d make a comment in Trello and then copy the link to the comment to send elsewhere.

Quality Guidelines

Production Ready Deliverables

Although a team lead reviews every deliverable, you should not rely on them to catch mistakes of omission, misunderstanding, or inattention. Mistakes are inevitable, but the best team members take accountability for their work and try to deliver it fully completed the first time.

All completed tasks are eventually sent to the client for approval, which closes the loop and secures their happiness (and payment). We can’t have that closure with partially done tasks.

We should always assume that clients don’t have a great imagination (mostly because they don’t fully understand your job, so it is impossible to imagine what you’ve done). They want it done right, the first time, quickly, and exactly.

Because clients don’t typically know how to code or design, it is hard for them to use their imagination to see the value they received for incomplete work.

Review Your Own Deliverables

Before submitting a deliverable for review, take a minute to review it for the following two things:

First, take a step back from the minutia and look at the overall quality of what you’re sending. If you’re a developer, take a look at the finalized code (your PR) and see if you left any debugging or unused code. If you’re a designer, review the finished product from the eyes of the client. Then make any final changes (if needed).

Second, double check that you satisfied all the requests and goals of the original task. Very often you’ll find that in the effort to get some of the large parts done you overlooked easy requests that when missed could slow the task from completion.

Proud of Every Deliverable

Every contribution should be your best work. You should push back on anyone who tries to stifle that. Sometimes you’ll have to push back hard and sometimes you’ll have to pick your battles, but every time you deliver a finished product, you should be proud of your accomplishments.

If your quality is being stifled by other team members, let them know. If your quality is being hindered by a team lead, make sure they understand why you did it the way you did and continue to mention it in the future. If your quality is being suppressed because of the client, use your best persuasive power to try to get them to do what is right for the project, but know that the customer is always right.

Self-documenting Code (developers only)

This guideline falls under Quality, but it is actually related to communication as well. Most developers think that when they write code they’re communicating with a computer to tell it what to do. What they are actually doing is communicating to future developers what the computer is supposed to do. As such, we write code that anyone on the team can (or should) understand.

In other words, we call variables what they are, we call functions what they do, we call classes what they are, we define complicated logic with descriptive variables, we call files what they are, we locate files in an intuitive location, and we take every opportunity to use code to document what the code is doing.

Consider the following:

if(person & person.id !== null & person.children[i].in_school & person.spouse.favorite_food === 'chicken'){}

There are lots of assumptions in that logic that may be true now, but need to change in the future. It is also very long to read and difficult to understand.

The following example is the same logic, but easier to read. Some developers would prefer the first, but only because they think they’re writing for computers.

var personIsSaved = person & person.id !== null; 
var hasChildInSchool = person.children[i].in_school; 
var hasSpouceThatLikesChicken = person.spouce.favorite_food === 'chicken'; 
var shouldGetDiscount = personIsSaved & hasChildInSchool & hasSpouceThatLikesChicken; if(shouldGetDiscount ){}

Thinking in terms of communicating to future developers causes us to focus more on the language we use. It become very important that we create and use language in a way that reinforces our system and it’s objects, relationships, functionality, and logic.