Outsight is an exciting training and mentorship program for bootstrapped tech start-ups that want to focus on the underserved market of the small and medium sized business solutions. Notwithstanding that focus, the program offers plenty of insight and knowledge for other business targets as well.
Led by Colin Schmidt, the CEO of Cnawlece Incorporated, participants will learn the ins-and-outs of both the business and the technology behind delivering financially viable solutions that:
- Are a Single Unified System
- Utilize True Incremental and Rapid Application Development Techniques for the Web
- Enable Long Term Support and Longevity
- Provide Long Term and Stable Revenue
The news is full of venture-capital-big-number-start-ups simply because small success stories are just not as entertaining to read about. This point however has the side effect of portraying that your only options are to go big or get hired; the truth is, you have another option.
Mutually beneficial deals is how real money is made on a long term basis and ecosystems are what make the world go-round. If you are tired of, or don’t like the prospect of chasing the next one-time web development job this program is for you. There can be more to the life of a web developer than sales and quick deliveries.
This program teaches you how to build your own ecosystem that centers around you, while you yourself are part of yet a larger system. In order to realize these goals however, you need to build on a platform that is tuned for such a business.
The Partnership Network
You sell to, customize, and support your clients; it’s your business. However, there are a number of downsides to owning a small business that need some attention and these key points are the main reason this industry sector is suffering so much.
First of all, there is only so much of you. It is probably a good thing that we are not cloning people (yet) and as long as this trend continues it is advisable to make other arrangements. It is a well-known and sad story: that of the small business owner, where the business controls and restricts life more than a salary job would; why bother? In order to keep your life in check AND still be able to deliver client expectations you must have a support system.
The hang up, that perhaps haunts this industry more than it does others, is that businesses and organizations are often scared to work with you for one simple fact: what happens if you get hit by the proverbial (or literal) bus? Most companies and organizations that lose their central business system and/or data go out of business very quickly; the administrators of these businesses and organizations know this fact very well and it scares them to death (even though most of them are far too polite to mention this to a small development firm.) Therefore a significant part of the sales pitch from your small firm must include assurances that life can continue for their organization even if yours doesn’t. It isn’t a nice thing to think about and plan for, but it is part of life and you need to address it if you take on these responsibilities or expect potential clients to buy-in. On the lighter side of all this dreariness; what happens if you just want to take a real vacation for once?
The second key point is that it is hard to do it all when you are starting out. Diversification of your business plan is not the same thing as doing everything in-house. Unfortunately, these two ideas are often confused to be the same in one’s mind. Focus what you are good at in multiple directions, take the rest of the equation and partner with people who live-and-breathe that topic.
The final item to address here is source code bases: How do you get started? Selling custom solutions at a profit is one thing when it is mostly built and you just need to customize and expand it. It is quite another if you have to build everything from scratch! The benefits of traditional open-source are huge; the negative aspects are, well, negative for business. Working with a Partner Network that shares all generic base-line code but does not require you to share client-specific or specialty customizations is a win-win.
Two heads are better than one when it comes to many things, and system design and problem solving are certainly on that list. Four hands can type more code than two, and growing that code base is easier when more code can be typed.
A community dedicated to this purpose can accomplish a lot.
The Moxie Web Development Platform was designed to fill the business needs of the above organizations: for both the developer and the developer’s clients. An affordable, profitable, and stable solution did not exist, so out of necessity, it was built. Here is a rundown of what it was built for.
Single Unified System
Most organizations, large or small, don’t look for a single unified system because they don’t think it is possible. When you offer it as a viable option however, the ideas quickly start flowing of how such a system could greatly benefit the organization and its clientele.
In contrast, multi-system integration for small markets is a nightmare and best avoided. The pitfalls are large and the odds are not in your favour: over time, there are just too many moving parts; security and management issues slowly creep in.
We are talking about a platform optimized for custom solutions, but here are some (of many) example building blocks that can go into such a system:
- Primary Public Facing Website
- Customer Relationship Management
- Point of Sales
- Community / Social
- Business Processes
- Business Data and Reporting
The beauty of a Single Unified System with all of the above is most evident when you consider the importance of each item above in relation to the others: each item as a standalone object provides only so much value. However, when you link them together in one system the barriers are removed and the collective value is a function of multiplication instead of an addition.
Rapid Application Web Development
It seemed that legacy desktop development was just to the point that the promises of RAD could be cashed in on when everyone dumped the platform and started to develop business applications in the web. The benefits of the web were clear, but the systems were not originally designed with the intent to service this realm. Then again, back on the desktop, some of the most RAD environments were also the most restrictive and probably didn’t addressed the whole solution stack. Indeed, RAD tended to be about User Interface development and the rest of the process was hardly changed.
In order to truly enable RAD Web Development you need a platform that provides and integrates the entire stack: the web server, database, content management system, programming language, and the administration interface all need to be a cohesive package. We are not looking to just re-package existing systems together, but actually have them designed from the start to fit together. Designed such that each component understands the other and can be smart in working together.
Incremental Web Development
IT Project Failure is a major topic that, quite rightfully, receives a lot of press coverage. The sad thing is that such failure is just as rampant, if not more so, in the small and medium business realm where it probably has a much larger impact on the lives of the people involved.
The most significant factor in any project’s risk equation is the project’s scope: the larger they are the harder they fall the saying goes, and it clearly applies. The reason for this is simply that each moving part of a project is going to multiply the risk, not just add to it. This should sound familiar. If you want the dream system described above, where the benefits are multiplied instead of added, you have to build it one little piece at a time.
For some reason, people are drawn to extremes until experience eventually pulls them closer to the center. Originally, computer systems had to be extremely structured to help keep it all organized because the systems themselves where complicated and everything being done was being done for the first time. We came out of this era with some bad rigid habits that the development community has largely revolted against in the more recent years; in many cases, they have swung too far in the other direction, and over time everything will settle closer to the middle.
If you want to successfully steer a long term incremental web development project, you need a platform that is flexible but structured. Flexible to change but structured to keep order.
Long Term Support and Longevity
In eras long gone, if a system worked, you let it run until it didn’t, and people prayed that day would never arrive. Security in these days was less of a threat than in today’s more interconnected world: for most systems today, you either take the time to patch or you will eventually get hacked.
Patching-Hell is sort of like the well-known DLL-Hell harking back to the desktop development days. The biggest problem with Patching-Hell however is that many pretend it doesn’t exist. When you build a compressive system with many individual parts, each maintained by different groups of people, it becomes increasingly complicated to keep the system up to date as time progresses. It isn’t an impossible job, solving DLL-Hell wasn’t an impossible job either; it is just a lot of work and increased risk.
It should be clear that as systems progress they tend to mature and improve, therefore another benefit of patching and upgrading beyond security is increased capacity and capabilities that are critical for today’s fast moving businesses.
Any system designed to exist long term therefore must have a simple way of handling patches and upgrades such that co-dependencies between system components is not an issue.
Despite patching, systems fail, your hardware fails, cloud service providers fail; things just go wrong. In these situations backups are critical, but not all backups are created equal. Backups need to completely cover every aspect of the system, they must be easy to restore to any other hardware/cloud, the restore must not have any potential to introduce bugs or security issues, the backups need to be frequent, and they must be small enough to allow for plenty of history at a reasonable cost.
Speaking of costs, long term costs are always a factor. The more you keep costs down for your clients the more money they can afford for development! In order to realize this, small low-traffic systems cannot require an entire server or virtual server to themselves: they need to share server space, even virtual server space, with others. Don’t forget however that they need to be sandboxed.
Covering off the above checklist of considerations is certainly doable in most systems. However, when a platform is built from the ground up to make the above as simple as possible, cost savings and risk mitigation are both drastically improved.