Why We Decided iOS-first Over Android for Our Mobile Apps

screensWe are often asked why we decided to develop our mobile apps in iOS rather than Android. And, it goes right back to our general business philosophy of giving our customers the best value for their dollar. It is generally accepted that developing in Android is more difficult, more challenging, more time consuming, and subsequently costs more.  In fact, some developers claim that Android development costs 2-3 times more than iOS.  Read about it in the post “The Fallacy Of Android-First.”

Why Don’t Designers Take Android Seriously?
It is largely held that iPhone users shop for bigger ticket items on their phones and mobile pads than Android users. Jim Edwards writes in Slate’s Business Insider, “Here’s Why Developers Keep Favoring Apple Over Android” and addresses some of the Socioeconomic reasons for this being the case.

Cennydd Bowles, a U.K. based design lead at Twitter, raised the issue recently in a thoughtful article on Medium titled, “Why Don’t Designers Take Android Seriously?” He wanted to know why app developers don’t like working on Android apps.

“Android is the dominant platform of the next decade with about an 80 percent market share in some areas of the world. Why aren’t designers paying it more attention?” Bowles asked.

He got a bunch of responses from his colleagues and readers.  In summary: The replies were mostly variations on the theme that Android users don’t pay for apps, they don’t have data plans, you can’t monetize them easily, and designers are all iPhone users and don’t really understand Android users.

But, the real heart of the matter from a developer’s perspective is, “Where’s the meat!?” Or, more appropriately, where are the development dollars being spent? Harry McCracken, writing for time.com, published, “The Smartphone App Wars Are Over, and Apple Won.” Here are some of this thoughts:

  • iOS users are more app-happy and free-spending than Android users. There are plenty of stats saying that’s the case, such as this one and this one. That makes iOS a more attractive market even though it’s got fewer bodies than Android.
  • Supporting multiple platforms is tough. Many of the most interesting apps come from tiny startups that pretty much don’t have the option of releasing two ambitious pieces of software at the same time. Something’s gotta give, and what gives is nearly always Android. Even big companies with lots of resources — such as Facebook, which released Paper as an iPhone exclusive — can’t do everything all at once. Which makes it that much tougher for Android to have a shot at pulling even with iOS, let alone breezing past it.
  • Developing for Android is a hassle. The obvious obstacle is the challenge of supporting a bevy of devices from different manufacturers, with varying specs and hardware features, running different variants of the operating system. But even without that factor, I’ve chatted with many coders who say it’s just harder to get a slick app up and running on Android than it is with iOS. How hard? Maybe twice as hard.
  • Sometimes the second platform a developer supports is the iPad. Such as the e-mail app Mailbox, which originated on the iPhone, and then arrived in a version nicely rethought for the iPad’s larger display. A year later, an Android version is still a to-do list item for Mailbox’s creators. Might it have shown up faster if there was no such thing as an iPad?
  • In the U.S., Android isn’t the runaway market-share champ. This country remains the single most important producer of smartphone apps, and Google, though ahead, isn’t creaming Apple here. In Comscore’s latest numbers, for instance, Android has 51.5 percent share and iOS has 41.8 percent. That reflects a small dip for Android and an uptick for iOS, an inconvenient truth for anyone who argues that Apple’s operating system is on an inexorable march towards irrelevance.
  • iOS has a cultural advantage in Silicon Valley. As far as I can tell, the majority of the tech execs who decide how to allocate development resources are still iOS users, personally. If they were all required to give up their iPhones for six months in favor of the Android device of their choice, it might change their perspective.

What Was the Deciding Factor for us in selecting iOS?

It is the cost to our customers. Simply put, we can develop an app more quickly in iOS. Sometimes twice as fast! That means fast to market, less time in production, and reduced development cost. That delivers value, and we value that.

Security Bug In OpenSSL Could Affect Much Of The Internet

A very serious bug in OpenSSL, an open-source software library that is used to secure most of the Internet’s sensitive traffic has been discovered and publicly disclosed. The bug is being called “Heartbleed”, has a lot of system administrators and security teams scurrying to secure their systems.

OpenSSL is probably a part of your life in many ways. If the apps you use, or the sites you visit encrypt the data they send back and forth, there’s a good chance they use OpenSSL to do it. The Apache web server that powers something like 50% of the Internet’s web sites, for example, utilizes OpenSSL. It seems that it’s possible to trick almost any system running OpenSSL into revealing chunks of data sitting in its system memory.

Why the concern?

mobile_securityExtremely sensitive data often sits in a server’s system memory, including the keys it uses to encrypt and decrypt communication. This applies to usernames, passwords, credit cards, and other sensitive data. This means an attacker could quite feasibly get a server to spit out its secret keys, allowing them to read to any communication that they intercept like it wasn’t encrypted it all. With access to those keys, an attacker could impersonate an otherwise secure site/server in a way that would fool many of your browser’s built-in security checks.

How Did It Happen?

OpenSSL is an open-source program which anyone can contribute to and improve. Changes are submitted and reviewed before being added to the final release. Website administrators are then sent this release to update their systems. This meant the error moved from development team to the released version and eventually the websites without being identified.

German programmer Dr. Robin Seggelmann wrote the code for a new feature; it was reviewed by another member of the open-source community and then added to the OpenSSL software on New Year’s Eve in 2011. It was a simple programming error which unfortunately occurred in a security relevant area. It was uncovered by a team of researchers from Google Security and Codenomicon.

Affected sites, including Google and Facebook, have fixed the problem, but there are still thousands of websites who are yet to fix the problem. Affected sites include a number of Google services, including Gmail and YouTube, Facebook, Tumblr, Yahoo and Dropbox. All of these sites have been patched, and security experts are advising people to change their passwords on these accounts, even if the sites themselves aren’t issuing the advice.

What Should You Do?

Qualys, a Web security firm, has developed an easy tool that lets you scan any website to see if it’s vulnerable to the Heartbleed bug. Go to the Qualys SSL Labs page, type in the name of a website, and click “Submit” to assess its vulnerability to the OpenSSL Web encryption bug. When the scan is complete, you should see a notification telling you whether the site is hit by Heartbleed.

There is also a robust list of Android, iOS, Windows Apps, Websites and Video Game Services affected by Heartbleed on this site.

What’s the latest updates?

It turns out that the Heartbleed security flaw may not be as dangerous as thought, and may not have as much impact as might have been originally feared. Now that a few days have passed, and stringent testing has been done, it appears that, while still a critical issue that needs to be corrected, it may not be as far reaching as it might have been. There is good insight into the current status at The Verge website.

April 14, 2014 – Akamai Heartbleed patch not a fix after all! The Web infrastructure company’s patch was supposed to have handled the problem. Turns out it protects only three of six critical encryption values. Here’s the article discussing the issue.

April 15, 2014Every password you should change because of Heartbleed (the ultimate list),

>by Harrison Weber

Heartbleed, the massive OpenSSL security flaw, has led to panic. Major companies scrambled to fix the bug, and in the aftermath, expects are preaching a simple recommendation to nearly all Web users: you should probably change your passwords.

Just about every company and every security expert has said the same thing about passwords for years:

You shouldn’t use the same password on every site.
You should change them often.

Rinse, repeat.

Some security experts say you should wait a bit before changing your passwords. That’s fine, but it’s likely not necessary, as most major Web firms have long issued fixes. If you really want to be careful, you can check to see if a site is still vulnerable to Heartbleed before changing your password on it. Here’s the link again: Qualys SSL Labs

Getting Real about Production Software


Last week, we got a call from a customer that one of their users had attempted to reset their password and received a “something went wrong” message from their app. Upon investigation, we were horrified to discover that their app had no email service running. Why so horrified? Here was the initial picture of the situation…

  1. CabForward deployed the app and was supporting the app, so it was our responsibility to discover and resolve any issues.

  1. One of the startup investors discovered the problem — not us.

  1. If the app’s email feature wasn’t working, it had likely not been working since we migrated them between cloud providers just prior to going live a handful of months ago.

  1. Transactions within the app require an email-based approval process and no transactions had been completed since going live.

Make no doubt about it. This was a very serious issue, and we treated it as such. Unfortunately, it appeared our relationship with this customer had likely reached its end. They had trusted us with their proud creation and we simply had not given it the attention it deserved. Well, okay, let’s get real! We hadn’t given it the attention that it required.


As CabForward CEO, I am frequently evangelizing the idea of Rugged Software to our employees, partners, prospects, customers, friends — pretty much, whoever will listen. But somehow we completely dropped the ball on this one. As in any similar situation with systemic or team-wide failures, many smaller issues often conspire to create the perfect storm. Having said that, if CabForward was truly as rugged as we aspire to be, none of these smaller issues would have been allowed to happen in the first place.

There were very few automated tests and little or no test coverage for this product. This customer had come to us with a product that had been developed by another shop — a dev shop that had recently switched to Ruby from another language and brought a few anti-patterns with them. The code quality score for this app was painfully low and little time or budget had been committed to cleaning it up — something that becomes more time consuming the larger a product becomes. What’s worse, the previous developer had convinced the product owner that they would write “the right mix” of tests, as if somehow justifying that the right 40% of code coverage is really enough.

There was no error reporting installed to capture run-time production issues. We completely missed implementing any error reporting on this application when we migrated between cloud providers. Software in production requires the full gamut of system testing and monitoring and this app had very little.

There was no real difference in the way we handled code in production versus other environments, like staging and testing. As developers, we believe that there must be strong consistencies between all of our environments. Without strong consistency, there is no confidence that the different environments would behave similarly. But this view of production as just one of the three or four standard environments can cause developers to forget how much more important production is than the other environments. As an organization, the way we treat the production environment must be different. If we are changing variables, data, and/or code on a whim, and without any real discipline, we are gambling with other peoples’ money and disrespecting their investment and interests. It’s the responsibility of the organization to educate its developers on the importance of structure and discipline and, in this case, we failed to do that.

There was no visibility or collaboration between development and QA/testing. When we adopted this project from the previous developer, we were assured that testing was being handled by a third-party. Testing should not be optional, just like quality and security should not be optional and it shouldn’t be disengaged from development. This leads to a question of accountability and breaks down team dynamics. DevOps is founded on the principle of intense collaboration and we’ve been studying the topic for years. Was this particular case so exceptional it didn’t apply? What makes an edge case and why? Sorry, no. No exceptions.

There was no quality control enforced by operations. Policies for standards across projects were not enforced at the time of this folly. We pride ourselves on our flexibility, but with too much flexibility comes the risk of chaos. Standards are there for a reason — enforce them or go into another line of work.

There was no real support agreement. Because we engaged with the customer near the end of their product development lifecycle, funds were low. This created a scenario where the customer felt they couldn’t justify the expense of our standard support agreement. So instead we coasted into one. We extended the original time and materials engagement to include support activities. This type of unstructured T&M support engagement simply doesn’t work because it creates a reactive vs proactive environment.

There was no excuse for any of this. We won’t let our customers talk us into a diminutive low-cost or no-cost support agreement again. We’re drawing the line. We didn’t explain the importance of these things and therefore the customer didn’t know to ask for them.

Regardless of all of these past decisions, we should have pushed harder to encourage, or even require, the development of more discipline. And that is really the primary offense. Product owners are often non-technical entrepreneurs who don’t fully understand the why’s and why-not’s that are so often obscure in most technology decisions. They trust us to be honest. They trust us to be professional. They trust us to enforce standards and communicate the reasons they exist. We could hide behind the veil of secrecy or shame here, but we’re coming out with it. We’re drawing the line.


  • Our customers trust us to mentor them and communicate effectively. By not saying ‘no’ to bad decisions, we are essentially enabling our customers to sabotage their own investment.

  • Our customers trust us to be professional and commit to doing things right. When we lower our standards, we are not standing up to our fiduciary responsibility to protect our customers interests. Not to mention their trust in us.

  • We will not allow our customers to fail based on false or unclear assumptions. Assumptions stifle growth and hinder creativity. Assumptions cause missed opportunities, erroneous beliefs, misunderstandings and errors in judgment. Assumptions can kill a relationship if they are incorrect or inconsistently understood between parties.

  • We cannot be swayed by a single customer or unique case from doing what should be required for all of our customers. A canonical system driven by best practices was implemented to provide governance and must be enforced. This practice should not require significant ramp up or investment beyond standard estimates. We cannot place this responsibility squarely on the customer — they shouldn’t have to pay extra to get what we suggest makes us different in the first place.

  • Risk cannot be deferred solely on the customer’s decision to accept it. We have to let the customer know that we insist on the structure; the customer is depending on us for our expertise. We must be willing to exit the customer engagement if the customer wishes to accept unnecessary risk in order to save a relatively small amount of money.

  • We must not hold back on ruggedization just because the customer is frugal. Instead, we should be fully committed to the ruggedization effort and apply it equally to every customer, every engagement, every product we touch.

  • Ruggedization requires a commitment to continuous improvement. In our efforts to keep support costs down for our frugal support customers, we constrained the subcontractors hours and thus met the customer’s budgetary constraints. However, from a Support perspective; this should have never been allowed to happen, because it drives the wrong results and the customer suffers due to our inability to find a more creative way for our customers to afford these quality and security measures.


We accept! We accept the challenge and take up the gauntlet. Some things must change right away. Let’s outline them.

  1. We will require a minimum fixed cost support contract to be in place for all production systems. A more rugged support contract will be proposed for higher traffic, more mission critical apps.

  1. We will do better at defining, documenting and explaining our project workflow and deployment processes. We promise customer visibility and must deliver without exception.

  1. We will set and agree upon a minimum grade requirement for code quality. We will continue to use and explain to our customers the importance of Code Climate, and tools like it, to demonstrate quality code throughout the project life cycle. This is especially critical if we are taking over code from another development team.

  1. We will exercise the application’s mission critical features regularly. We will require a comprehensive set of test cases. From this list, we will require that the business owners declare which of the test cases are mission critical. These mission critical test cases will be subjected to regular exercise and validation. When testing the service dependencies used by the application, we must test the same plumbing used by the application itself. No more blind stubbing! Blind stubbing is not really exercise — it’s like saying “I thought about exercising,” but is not true exercise.

    We will no longer allow our customers to assume that their app is healthy without clear and regularly scheduled proof. Generic application-wide code coverage is not an accurate representation of risk. Success is not about 80% code coverage or 90% code coverage — even 100% code coverage is not a clear indicator that your app is actually going to work when it’s game time. True success is about regularly exercising 100% of the app’s mission critical plumbing.

  1. We will enforce pre-release conditions anchored in three primary documents. These documents already exist for most support projects today, but are of inconsistent quality and are inconsistently managed. Regarding handoff of this application to or from CabForward℠, these three documents are required. Any system that is promoted to production by our team will require these documents. Handoff of existing applications to CabForward℠ would follow this same requirement — before we accept a new production application, either the customer will require this documentation to be supplied by the former developer, or we will be hired to produce these documents. This will assure that risks will be identified and understood. During the on-boarding and off-boarding processes, we will list and validate all assumptions.

  • Application Architecture - This document will include the initial user stories, the proposed architectural diagram, and all touchpoints with third party utilities along with full descriptions of intent of use.
  • Operations Administration – Explains the system architecture at a very detailed technical level, including how to set up the environments and full documentation on 3rd party touchpoints. This document will also contain all login details and service ownership details for infrastructure components. Furthermore it will outline agreed upon acceptable levels for risk, including what degrees of monitoring, code analysis, testing and self-healing is sufficient for the business.
  • Release Plan – This is the documented plan for taking the product from staging to production, including sign-off from the customer and detailed instructions on how to push all releases to production. High level snapshots of differences should be presented to allow non-technical stakeholders to understand what exactly is being pushed to production.
  1. We will maintain operational readiness by leveraging continuous delivery systems that address any/all issues with repeatability, reliability and process continuity in real-time. We will test every build and require that all pre-release conditions are met as part of every iteration towards release. This will be done without exception and will be enforced at the level of the organization rather than the developer.

  1. We will continuously audit and improve our internal systems and processes. We recognize that our current systems are imperfect and require attention. The systems put in place two years ago are no longer adequate. We will not be beholden to any single system or antiquated tool or one way of doing things. We will embrace and enforce the concept that a system is not rugged without many different types of software running in many different places looking for many different things.


The lessons we have learned here will take us into tomorrow. We cannot and will not stagnate. We will not be content with previous standards. We will iterate. We will learn. We will embrace each challenge with honesty and humility. If we fail, we fail forward — fearless because we are true believers in the rugged way. We will build a better, stronger, more resilient team, process, product, customer, relationship, standard.

Our customers trust us with their products. They trust us to be technology professionals. We have an obligation to be more than just an assemblage of cowboys. This is our promise to our customers. And we must to continue to push ourselves to stay current, sharp and ready for battle at any moment. This is the rugged way.


I invite you to join us in our mission to be more rugged, to stop making excuses. To strive to make fewer mistakes, and when you do, share your failures and learnings with the world so we can all benefit. The idea of “rugged” starts with a personal commitment to quality and excellence, but it can’t stop there, especially when you’re the CEO. No excuses, no exceptions. Pick up the gauntlet. Let’s go!


Society of Rugged Developers

We all trust software with our daily lives, finances, safety, government, communication, business, and general happiness. But, how far should that trust extend? The Society of Rugged Developers is wading into the topic of ruggedness, because when it comes to software, it needs to be so much more than just secure. It has to be ruggedly reliable and defensible against attack. Software ruggedness is going to become increasingly important to applications, and enterprise systems, in the future.

CabForward bulb 2014The Society has a podcast initiative hosted by James Wickett and Lance Vaughn, Austin software developers, to define and refine the concept of Rugged as it applies to software. In the series of podcasts, they explore application security and the various attributes of rugged. In Episode 5 they chatted with Jeff Williams, co-author of the Rugged Manifesto. Jeff explained that “Rugged” came about as a result of his interactions with Josh Corman and David Rice, all of whom were frustrated that Application Security was not improving in an organic manner, and that they wanted to make a difference in that sector.

In setting the groundwork for discussion in the podcasts, James and Lance began exploring how to clearly define “Rugged Software,” and how the Rugged concept can be applied to the Minimum Viable Product with the Rugged Manifesto in mind. DevOps is also going to be very important in the future of  ruggedness. Once the foundation has been established, and the MVP can be built ruggedly, the rugged attributes will naturally scale as the product grows in scope.

While security of the software is at the heart of the rugged discussion, there are other factors to consider. The security industry has a lot of very good, proven, rules, but they tend to be too broad; they need to be distilled down into software security principles and practices. Rugged organizations operate as cross functional teams that value collaboration, seek out threats and build processes to protect themselves. The same principles need to be applied to software in the future.

What is Rugged?

Here is how James and Lance have posited the attributes of Rugged Software:

Attributes of Rugged Software

Security Reliability Maintainability
Defensibility Availability Longevity
Sensibility Recoverability Portability
Survivability Observability
Predictability Controllability

How would you define “Rugged Software?” Any suggestions you have are very welcome. The podcast website is currently undergoing development, and it will become the location for ongoing discussion of everything rugged when launched. In the meantime, we invite your comments, suggestions, and other thoughts in the response section below.

Security Vulnerability Announced in the Psych Gem

The Heroku Ruby Team has provided instructions on how to repair the security vulnerability announced with the libyaml library used in the Psych gem. This applies to all Ruby (MRI) applications on Heroku. This vulnerability could lead to arbitrary code execution when parsing YAML. To ensure you are running on the patched version of ruby, please follow the steps below.

Check to See if You’re Affected

Run the following on your app:

$ heroku run “ruby -rpsych -e \”p Psych.libyaml_version.join(‘.’)\”” -a

If you see the following error message, then you are not vulnerable and can ignore the rest of these steps:

:29:in `require’: no such file to load — psych (LoadError)
from :29:in `require’

If you are using Psych, the command will return a version number. If the version returned is less than 0.1.6 you are vulnerable. Please follow the instructions below.

If you do not explicitly use the Psych Gem:
If you don’t explicitly use the Psych gem and you’re on Ruby 1.9.2+, you’ll need to push a new commit to your app, which will cause a deploy and update your version of ruby automatically. If you don’t want to push any actual changes, this commit can be empty:

$ git commit –allow-empty -m “upgrade ruby version”

$ git push heroku master

If you use the Psych Gem < v2.0.5
If you’re using the Psych gem in your Gemfile, update Psych to 2.0.5 which includes libyaml 0.1.6. Change the Psych gem line to:

gem ‘psych’, ‘~> 2.0.5’

Then update your gems, commit, and push.

$ bundle update psych

$ git add Gemfile Gemfile.lock

$ git commit -m “update libyaml to 0.1.6, CVE-2014-2525”

$ git push heroku master

If you have any questions, contact Heroku

To Build Or Not To Build?

It is a foregone conclusion that the future of all computing – consumer and enterprise – is mobile.

iphone-5Consumers are busier, move quicker, and expect faster tools to improve their daily activities. Employees are consumers. In both cases, businesses must decide which tools their users require and then move quickly to fill that need, or else risk the likelihood that a competitor will do it first.

No one can blame a business that hesitates to invest in new technology. The web is littered with apps that never captured the market. Similarly, countless enterprise organizations have stubbed their toes developing new software that underperformed or was underutilized by their staff. But the uncomfortable fact remains: those companies that fail to embrace technology will struggle to compete and stay relevant. Once a genuine need is discovered, the six million dollar question is not whether an application should be built, but rather how rapidly and efficiently can it be done.

Let’s Talk About Toys

What can toys tell us about careful construction of new technology?

There have been no less than a dozen companies that manufactured interlocking blocks. Minibrix. Tente. Erector. Lincoln Logs. Kiddicraft. There were other flash-in-the-pan makers of construction toys for kids. Each company attempted the same goal, but none captured the imagination nor met the demands of users (kids) quite like LEGO. And yet, like many massively popular brands, LEGO nearly went bankrupt.

Lego logoLack of focus, mismanagement, uncontrolled costs, failure to fulfill the demands of their buyers, and a haphazard approach to innovation nearly destroyed the LEGO legacy. In software terminology, the events leading up to LEGO’s near demise were the opposite of lean.

Much like the toy itself, LEGO went back to the basic building blocks of their success in order to regain their hallowed position in the market.  They eliminated under performing products, sold unnecessary divisions of the LEGO brand, solicited greater feedback from the public, and exerted more control over their innovative endeavors. What pain could they have avoided had they embraced a lean approach to their growth? Millions of dollars in revenue and a vast backward slide in brand value.

But Apps Are Not Toys…

Drawing Board reverseYour company has multiple pieces. Many of them are employees. As you survey the market and assess your challenges, it’s apparent that your company needs to change. More pieces are required to improve your process, reduce inefficiencies, find new revenue, extend the reach of your operations, or bring order to your company’s many moving pieces. That’s where new technology snaps into the holes to strengthen your organization.

Accept the fact that the time to invest is now.

Then enlist our team at CabForward℠ to help you identify your challenges and clarify a solution. Our approach to software is lean, agile and rugged – three powerful methodologies that will let you avoid the near death experience of LEGO.  We’ll construct the working foundation of your technology with the basic blocks needed to solve the main challenge. Once we validate the solution, you can reap the rewards of your investment and then invest again to build upon it. Our approach gives you the ability to quickly deliver a solution and avoid the dangers of doing nothing, doing too much, or doing something too slowly.

Learn more about CabForward℠ or contact us for more information on getting started today.
Contact form


8 Steps to a Lean Canvas Business Plan


Lean Canvas

A planning tool we found helpful in designing our own CabForward℠ business, and helping others plan theirs, is the Lean Canvas. It is a delightfully quick way to define your business, without the need for a full business plan. Lean Canvas uses a 1-page business model that helps an early stage startup iterate quickly through their challenges and target markets, define their unique value proposition, test assumptions, and ultimately arrive at their first iteration Minimum Viable Product (MVP).

The Lean Canvas helps the startup entrepreneur gain clarity about their business idea that translates into a better defined approach to their market(s) as well as potential investors and end users. We use this tool in our Discovery Sessions because it blends well with our lean and agile approach to business. You can read more detail about the Lean Canvas in our Startup Handbook, which is available for download upon request. Below are the eight primary points in list form, which lay out the road to success in using this approach.

8 Steps to A Lean Canvas Business Plan

1. Interview Customers The fastest way to learn is by talking to customers.

2. Clarify the Problem Survey potential users to validate the problem you’re addressing actually exists.

3. Validate the Solution Ask potential users if they think the concept solves the problem, and how much they would be willing to pay for it.

4. Set Your Price Testing pricing early and getting paid is the ultimate customer validation in a lean startup.

5. The MVP Interview Ask for feedback from users. Is your MVP providing the right solution(s)?

6. Measure Your Product Fit Create a customer feedback loop to help you understand how your MVP is being used, and what features users would like.

7. Get Ready to Sell While you’re building your MVP, get a website up with a teaser page to let folks know that the product is coming.

8. Make Feedback Easy Post your number on the website. Set hours. You are your product’s Tech Support, and the calls are a continual learning loop.

Tech Support is Customer Development

While the personal phone call is an excellent tool, you’ll need to provide multiple ways for customers to get in touch with you: email, Twitter, Facebook, LinkedIn, other social media that fits your marketing approach, your blog, and a feedback form on your site. A 5-percent increase in loyalty can increase profits by 25%-85%.

Check out Google Forms for simple processes for the collection and organization of info made simple. You can run surveys, collect RSVPs, build your mailing list, and then check out the results, neatly organized in a Google spreadsheet. There is more detailed information in the Startup Handbook and on the Lean Canvas website. We encourage you to take a look. It will help you to verbalize the who, what, when, where and how as you gain clarity about each of these.

Do you have a success story about Lean Canvas? Drop us a comment in the window below. And, certainly, if you have used it in some unique way that works for you, we’d like to hear from you. You can also request a copy of our Startup Handbook.

Startup Handbook request

Cab Forward View At CabForward℠

CabForward℠ adopted, from the inset, agile software development practices and lean process controls. Those practices are a very good fit for our philosophy and the way we want customers to feel about being in control of their project. We have had some missteps along the way, as all businesses do, but we always strive for excellence in every engagement.

CabForward designs and builds apps

We Architect Apps

Whether the project is a mobile or web application, Ruby on Rails or other open source framework, the process is the same, and our objectives unchanged. We wanted to find a way to give the client more control during the development cycle, so we looked for ways to put them in the driver’s seat. So, we turned the waterfall project management process around, putting the client “up front” in the development cycle. That’s how the name CabForward℠ evolved. It imparts the overriding passion we have for providing the best customer experience available. That’s also how our initial business slogan evolved; “We Build While You Drive.”

Waterfall and Big Design Up Front

It is often argued that the waterfall and Big Design up Front project management processes, in general, can be suited to software projects that are 1) stable (especially those projects with unchanging requirements, such as with shrink wrap software) and, 2) where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started, and, 3) that implementers follow the well-made, complete design accurately, ensuring that the integration of the system proceeds smoothly.

We took the best of both models and revised them to better fit agile and lean principles. The Big Design Up Front is at the core of our Discovery Sessions, which are designed to save our customers time and money by creating an overall approach to their project, developing User Stories, and defining each step of the development process from the Minimum Viable Product through to subsequent development sprints. We use elements of the waterfall process, too, we just switched them around to give the customer more control of their project through our own transparency.

Cab-forward Becomes CabForward℠

We wrote previously about how our company name, CabForward, came from researching cab-forward perspectives in various industries and how innovation was applied in those cases to improve applications and processes. We searched for corollaries in other practices that could validate our approach. The earliest use of the term “cab-forward” that we could find was the description of how a locomotive was positioned backwards at the head of a train to put the smoke stack and exhaust chest behind the crew.

In Origin of the Term Cab Forward we examined why railroads used that practice. The problem that ensued was that it put the tender in front of the locomotive, and tenders are intended to be pulled, not pushed, which limited the speed of the train. The solution was to redesign the locomotive so that the smoke stack, steam chest, and the tender, were behind the cab.

Some of the interesting detail we discovered along the way were things like the smoke stack that extended back over the roof of the cab, such as in the Rogers Consolidation locomotive, and the attempts to protect the crew through the use of smoke hoods.

That same innovative process was applied to motor vehicles, as well, when we researched trucks and cars that use the cab-forward design to provide better experience for drivers.

All of these principles revolve around a desire to protect the driver and elevate the overall experience. That’s what we wanted to do in our business; to put the customer in the driver’s seat, give them clear vision into what is going on, and give them control to speed up or slow down as necessary. The CabForward process works, and have many happy, repeat, customers who like this new approach to the development cycle.

Contact us for more information on how we can help your project.
Contact form

Project Management

Project management is one of the greatest challenges for the customer as well as the Strategic Technology Partner selected to do the development. We have experimented with several business tools and processes, and are happy to share some of our findings to date.

We can also share that engaging with customers before you have your processes in place can cause you to lose them, because they see you as ill-prepared, and perceive you as unprofessional. It happened to us in our startup phase here in Austin.

Collaboration is key to the way we like to operate, and inherent in that is good, clear, focused communication. We like for our clients to be able to see exactly where we are in the development process at any given moment, and we want to be able to track their thoughts and instructions.

Project Mangement

Puzzle Piece


We tried Jira for project management initially, but then moved to Basecamp, an easy to use, agile project management tool that provided a record of discussions between the customer and software development teams working on the project.


We used Harvest, from 37Signals, for time-and-expense tracking on our projects in our second year of business. As always, though, you can run into questions for which there isn’t an apparent answer, and you have to resort to using the Help function. Since we frequently use contractors with specific skills for special projects, we had questions about removing them from Harvest when we don’t need them (saving a monthly per-person fee). Tech support replied quickly to our questions, and got us moving forward. We like that.

Pivotal Tracker

We tried tracking User Stories in Jira early on, but found that for us, it just wasn’t a good fit at that point in time. We hadn’t developed our internal processes well enough. Not to say that we might not try it again later on, but we switched to Pivotal Tracker, an easy to use, agile management tool that provides really good collaboration. Pivotal Tracker brings everyone, even distributed teams, into the same discussion, where they can discuss and agree on priorities and stay on target with Tracker’s continuous, automatic prediction of milestone completion dates.


In October of 2013, we moved to the new Mavenlink app which included the features of Basecamp, Harvest and Pivotal Tracker. As so often happens, a new, agile, product appears that makes managing day to day business much easier, and Mavenlink was one that we adopted quickly after its introduction. It is online project management software with unlimited projects & team members and lets us prioritize tasks, set deadlines, and plan milestones on Gantt charts. We began the switchover after a couple weeks of testing, moving to the platform completely in mid-November.

Sales Management

2 Piece Puzzle


Salesforce was a major part of our operations as it helped us keep track of the details necessary in tracking customer relationships. We kept a list of our partners, prospects and clients in Salesforce, and entered each contact with them, posted reminders about when to follow up with them, and could add to-do reminders that help keep us on track.


We experimented with Highrise for a short while, and it does a great job, but we returned to Salesforce for its richness of features that we value. Your situation might be different than ours, so you owe it to yourself to check out the alternatives.


We recently moved our sales and CRM functions from Salesforce to Pipedrive for Pipeline Management. We find that with our distributed sales team
Pipedrive helps us focus on the right deals, it’s easy to use, and our salespeople like its simplicity.

Phone and Video Conferencing

3 Piece Puzzle


For those times when we are away from our computers, but need to have a conference call, we use ÜberConference. With UberConference, conferencing is a breeze. First, forget the pain of finding and typing in long PINs. Participants can just dial into the conference number and will be automatically authenticated based on their phone number.


A key element of successful relationships is communication, between team members, and between us and our clients. We use Skype, which is available, free, for desktop and mobile devices. When you’re away from your desk, you can still keep up on what’s happening with a smartphone or tablet.

We have several conversation threads going at any given time. We have a thread for developers, another for the Customer Development team, one for the leadership group, etc. We also create a thread for each client while we have their project underway, so they and the developers can have instant contact with each other. We also upgraded to the premium account, which gives us multi-user video conferencing.

We initially tried Campfire for this, but found that Skype fits our current needs better. One thing we particularly like about it, is that it stores all comments in all threads, and archives the conversations indefinitely, displaying messages however you need them: Today, Yesterday, the Last 7 days, Month, the Past Year, or from the beginning of the thread. This has been extremely helpful in going back to recover important discussions.


We’re currently also using HipChat, which features group chat and instant messaging built for teams. it gives us persistent chat rooms, drag-and-drop file sharing on desktop, mobile, and web apps. It eliminates a lot of the delay we experience in Skype, since we can send instant notifications to team members, and even invite guests into the conversation. You can also hop into a 1-to-1 chat with a coworker anytime, and if needed, video chats and real-time screen sharing too.

Google Hangouts

Using Google Hangouts, our Scrum master can bring together development teams to catch up on progress, what might be blocking completion of a feature, and any other issues that need to be discussed. Hangouts video calls are limited to 10 video conference participants, with no time limit. You can also use Hangouts On Air to broadcast a Hangout to many more people, though there is still a limit of 10 active participants. If you activate Google+ premium features, the limit increases to 15 participants for Hangouts created from Google Calendar events.

Data Storage

4 Piece Puzzle


We have used Dropbox from the inception of our business, because it gives us the ability to keep files up-to-date across multiple devices and stay in sync with our teams. Long gone is that “lost” feeling when you need access to a file that only resides on your desktop back at the office. There is a free account to get you started, and then as you grow you can upgrade to Dropbox for Teams offers administrative tools, phone support, and as much space as you need.

Google Business Apps

Google Apps for Business has become a workhorse for us as it provides familiar productivity tools that help you work the way you want, from anywhere, with anyone, and on any device. We give everyone on our team a Google business email account, which comes with shared and private calendars (with notifications and meeting scheduling), documents and spreadsheets (which can be shared with team members you select), and other tools that help us communicate more effectively.

You can access email, calendar, and docs from any web-enabled device, no matter where you are, and collaborate in real-time on Google documents, spreadsheets, presentations, and share emails, files, and other information with just a few clicks. We love to put a draft document up, invite team members to collaborate, and try to keep up as ideas start flying, all in real time. Its a very fast way to get something moving forward when you’re under a deadline. Try a free 30-day trial. It only costs a few dollars per user/each month if you want to continue.

What has your experience been with business tools? Are there some you prefer that you’d like to share with someone who is searching for the right tool? Please feel free to share in the comments section below.

Website vs Web Application

In a recent conversation with one of our customers, we asked how they came to select us as their Strategic Technology Partner. The answer, reduced to its essence, is that they had to do a lot of legwork to find a competent local developer that could turn their design into a working application at a pace that eased the financial burden.

He had first engaged with an off shore development company, and ran into the typical problems of insufficient communication and language barriers. He then engaged with an out of state company that was technically capable, but lacked business processes, communication practices and change control. He stated that there were so many bug fixes required that his investment to date was three or four times the original estimate.

His next big challenge was to learn the difference between companies that do website development and those that do web application development. He, and his investors, had spent a year deciding which company to partner with. He interviewed a number of companies that could do an outstanding website design but couldn’t do the transactional back end applications. That’s when he began to understand the difference between the two types of companies. He said, “Your industry needs to get better at explaining the difference.”

ridescout_preview_smallI think he’s right. When he made that comment I noted it down. I thought I could state the difference clearly, but as I began doing a little research to see if I could find an authoritative definition, the lines began to blur. So, I’m going to take a stab at it, and ask for your comments, to see if this can be better stated.

Web applications, or, “web apps.” are very popular today due to the availability of web browsers, the variety of tasks performed, and the convenience of smart phones and tablets. Common web applications include web mail, online retail sales and auctions, social networking, locating resources, driving directions, and all the other apps you use on your smart device.

So, how to explain the difference?

A “web app” is any custom software that runs in a web browser and accesses application files on remote servers. Web applications are usually developed in open source software such as Ruby on Rails, Django, or Symfony, which are web application frameworks. These frameworks facilitate development by allowing a development team to focus on the parts of their project which are unique to their goals without having to resolve routine issues such as user management, which have already been coded and imbedded in the framework.

Websites are getting more responsive, so it can be harder to distinguish which is which. A website, such as Amazon, has many applications running in the background.

Website development is generally split up into User Interface coding, covering aspects such as the layout design, and “back-end” coding, which connects the website’s functionality with behind-the-scenes applications such as a shopping cart. Website developers typically provide Graphic design, User Interface Design, Information architecture, Navigational Structure, and Copy writing with cross-browser usability, accessibility and search engine optimization in mind.

What Do You Think? Given the challenge of making the distinction between these, how would you state it?