At Apiotics we're about helping web developers build great IoT apps quickly. To help you do that, we've developed a set of 11 principles for IoT success that I'll share with you here.
- Work in an environment friendly to individuals and small teams
- Work on the frontier
- Embrace Conceptual Compression. With it, a small team can quickly build full solutions
- Don't waste time optimizing things that don't matter (yet)
- Don't build the wrong thing
- Use the time you save to talk to your users
- Take advantage of your small team to be responsive
- Use the freedom of not caring about things that don't matter (yet) to be more productive
- Resist the fear, uncertainty and doubt that will come your way
- Optimize later
- Head West
1. Work in an environment friendly to individuals and small teams
"Washington is not a place to live in. The rents are high, the food is bad, the dust is disgusting and the morals are deplorable. Go West, young man, go West and grow up with the country."
"The wild lands of the country should be distributed so that every man should have the means and opportunity of benefitting his condition."
The U.S. Homestead Act of 1862 opened up huge areas of the American West to settlement by individual families. It gave up to 160 acres to families who were willing to settle on and improve the land for at least 5 years. In so doing, the Homestead Act turned the American western frontier into a transformative opportunity for individuals and their families to improve their lives.
Critically, the structure of the Homestead Act advantaged small farmers rather than large corporations. As a result, the wealth of the frontier was relatively broadly shared among those who chose to settle. To be sure, there were injustices aplenty. African Americans were largely de-facto excluded, and Native Americans were de-jure excluded from a process that expropriated land from them.
Nevertheless, the structure of opportunity for the settlers who settled the American West would have been very different without the Homestead Act. One can easily imagine huge enterprises buying up the land and renting it out to tenant farmers; perhaps using the sharecropping system that emerged in the American South, where land ownership was not widely shared.
When you think about the frontiers that are available to you, it's worth thinking hard about whether they are structured to offer you a homesteader's farm, or a sharecroppers cabin.
2. Work on the frontier
Now, clearly, there's not a literal frontier available in the United States anymore. The last Homestead Act claim was filed in 1988 for 80 acres in Alaska. But, there are frontiers to settle.
These frontiers are new technology platforms. Platforms come on the scene, mature and some eventually fade into legacy systems. We've seen this happen with mainframes, minicomputers, the PC, the Web, mobile, etc.
But, a platform need not necessarily be a hardware platform. Programming languages, frameworks, cloud infrastructure all provide tooling and conceptual space for software developers to develop solutions for users. And, really, platforms are broader than simply a set of technological tools. They are tools plus the economic and social ecosystem (companies, people, open source projects, etc.) around those tools.
While a platform is relatively new, it represents a new frontier to be settled. The settlers will build great things for users. But, how those settlers prosper, or don't, has everything to do with the structure of the frontier on which they've settled. And, just as the Homestead Act represented a deliberate choice to structure the frontier to enable settlement and development by individual families, the people and organizations that create platforms structure those platforms for or against individual developers and small teams.
For example, perhaps you've got an idea to make a new microprocessor. The software tools you'll need to design the chip cost hundreds of thousands of dollars, getting a mask set done on a recent foundry node costs millions and you'll also need to build out an extensive set of software tools so your users can program it. It takes a fair sized team and a reasonable amount of capital to get it done. And, once you've done it, you'll need to earn your investors a return.
Now, there's nothing wrong with that. But, the opportunities in that space are not efficiently sized for an individual or even a team of a few individuals to tackle.
Artificial Intelligence is another field that looks to be structured against homesteaders. While the algorithms, programming frameworks and hardware required are increasingly available and comprehensible to the individual developer, getting enough good data to train an AI is a big and expensive undertaking. No wonder that the biggest technology companies are laser focused on the AI space. Given the typical data requirements, it is a natural fit for players of their scale.
At this point you may be rushing to point out all of the exceptions that I am glossing over here. There's no question that there are exceptions. But my point is simply that these exceptions are exceptions. As a general rule, the structure of a frontier platform has a great deal to say about the structure of the opportunities to be found building applications on it.
If you want to be a homesteader and not a sharecropper or a plantation owner, what you want is a frontier platform that has opportunities scaled appropriately such that a generalist developer, or a few of them can tackle the opportunity themselves. The more you need to build a team of specialists and/or gather a large amount of resources in order to build a solution, the less homesteader friendly that platform is.
Some people think that platforms that are friendly to homesteaders must also be inhospitable to large organizations. But that just isn't so. The same structure that makes building solutions efficient for a single developer or a few developers makes building solutions efficient for large organizations too.
Consider the Web. The Web is in many ways the quintessential homesteader platform. A single developer or a small team can rapidly build an app that solves real problems for users. But large organizations can be extremely productive building solutions for the Web too! There's nothing that shuts big companies out of building solutions on the web. But there are structural dynamics on other platforms that make it very difficult for an individual or a small team to bring a product to market.
The point is we're all better off, whether as an individual or a big company, developing solutions on platforms that work for homesteaders. Not everything can work this way. I'm pretty sure that Elon Musk needed to raise a bunch of money and put together a big, great, team in order to get Tesla off the ground. You simply need a lot of resources and people to build cars.
But, wouldn't it be awesome if you didn't?
3. Embrace Conceptual Compression. With it, a small team can quickly build full solutions
When we started building Apiotics, I wanted to see if we could meaningfully shift the Internet of Things to be a platform friendly to homesteaders. To do that, we needed to create a platform that would allow a single developer or a small team the ability to create a complete IoT solution.
There are a number of pieces that go into that, but perhaps the most important is Conceptual Compression. Conceptual Compression is a term that I am shamelessly stealing from David Heinemeier Hansson (along with any number of other ideas in this post). What I think @dhh means by that (and what I know I mean by it) is a mechanism that reduces the number of concepts developers need to have loaded up in their head in order to build a great product. Ideally, it reduces the number of concepts down to the point that a single developer can build a great product.
Just about any technology product, and certainly any application in computing, stands on a stack of dizzying complexity. Transistors, particularly those in microprocessors, are pretty complex. And so are processor pipelines, caching memory hierarchies, virtual memory systems, operating systems in general, assembly language, compilers, interpreters, linkers, libraries, imperative languages, declarative languages, databases, and vim.
Now, if you're building an application in computing and you want to understand your application at a fundamental level, then you need to understand most or perhaps all of these topics. And if you want to understand, in particular, the performance implications of various decisions that you're making, then you need to understand most or perhaps all of these topics pretty deeply.
While there are individuals who do understand all of these topics deeply, I am pretty sure that you are not one of them, nor am I. So if you or I want to build an application and have it be understood at a fundamental level, we need to build a team that, collectively, understands the application.
Alternatively, you could rely on the Conceptual Compression provided by your platform to just not worry about this stuff.
After all, the primary reason that you need or want to understand your application at a fundamental level is because you want to make decisions in light of that information. This seems like a very reasonable thing to want to do. And, platform builders think this is a reasonable thing for you to want to do as well.
As a result, they expose tons of different levers to pull and switches to toggle so that you can make all of these decisions in the right way for your application. Since these platforms are technical platforms the data you need to make these decisions in an informed way is technical data. Specifically, you need technical data about the way the performance of your particular application varies as these different levers are pulled or switches toggled.
In an ideal world, you would already have a running production instance of your application and the flexibility to simply make these changes, observe the results, and select the best set of platform settings.
In the real world, you never get to do that because the first time the application goes down under a bad set of platform settings the torches and pitchforks will be out and coming for you.
So, instead of doing that, you bring together a team that collectively understands your application at a fundamental level so that you can, as a team, Make The Right Decisions.
The thing is, most of the time it just doesn't matter.
4. Don't waste time optimizing things that don't matter (yet)
There's a classic book on manufacturing called The Goal and in it the author, Eliyahu M. Goldratt, describes his Theory of Constraints. There are many great insights in this book (which I won't attempt to fully summarize here) but one of them is that the only way to improve your business is to identify what your business is currently constrained by and improve it.
A short example from manufacturing will serve to make the point. Let's say that you have a machine that makes widgets and a truck that delivers them to your customer, who pays you when the widgets are delivered. The truck can deliver 100 widgets per day and the machine can make 200 widgets per day.
In this widget making operation, any effort you put into improving your widget machine is totally wasted. In order to sell more widgets, you need to improve your truck. Maybe you need more trucks, maybe you need a bigger truck, maybe you need a better driver. But whatever it is that you need, until you can deliver at least 200 widgets per day you don't need an improved widget machine. The widget machine is not the constraint.
And, in almost all cases, your technology stack/platform is not the constraint either.
Most of the time, the team you bring together to Make The Right Decisions is just improving the widget machine. Yes, maybe someday it will be great to have one that can make 1,000,000,000 widgets per day, but today you're just wasting time, effort and money filling up your plant with widgets that your truck can't possibly deliver to your customers.
And why is that? It's because that huge pile of technology you're building your application on top of is really really really awesome. And, it gets better all the time. The widget machine above would more accurately describe your technology stack if it more or less doubles its output every year, for free.
Now, given the complexity of whatever stack you're on it is true that there's no end of improvements you could make if you apply sufficient talent and time. And these improvements are often seductively objectively measurable. 10% improvement in boot time! 15% reduction in memory footprint! But you don't need to make them. At least, you don't need to make them yet. Doing nothing will get you huge improvements year after year. Your stack just isn't your constraint.
What is the constraint? Making something people (or companies) want.
5. Don't build the wrong thing
In the Internet of Things, doing this is a particularly pressing problem.
Cisco published a survey last year called IoT Value: Challenges, Breakthroughs, and Best Practices. In it there are any number of interesting nuggets, but the one that most struck me is that nearly 75% of corporate IoT initiatives fail.
Digging a bit deeper, the survey shows a really interesting split between technical and non-technical responders.
If you look only at the responses from non-technical executives, and not from the technical executives, the non-technical believe that only 15% of their companies' IoT initiatives were successful. Where the technical folks think 35% are successful.
What accounts for the split?
I think there's no question that the widget machine accounts for the difference. You can just imagine a technical executive saying to himself as he fills out Cisco's survey: "well, it's true that nobody actually wanted our electric frankfurter, but damn if it doesn't have a bitchin back end infrastructure."
The survey also asked its respondents to list the main difficulties with the IoT, and here's what they said:
- (Too much) time to completion
- (Lack of) internal expertise
- IoT integration (is too hard)
- Budget overruns
- (Low) quality of data
Of these, I think quality of data is the most interesting. Normally, low quality data is a signal vs. noise problem. There's a whole deep technical field devoted just to overcoming this problem, but I don't think that's really the issue with the IoT.
After all, we have really great sensors and the ability to collect enormous amounts of data incredibly cheaply. And signal processing, as complex a topic as it is, is pretty commoditized. You can buy an incredibly sophisticated digital signal processor to extract good data from a noisy feed for literally tens of dollars.
No, low quality of data means they built the wrong thing.
The data is likely to be quite clean and comprehensible from a technical stand point, but that doesn't mean that it actually adds any value. You could, for example, build a great weather monitoring system that provides real time data on precipitation, humidity, cloud cover, wind speed and direction, etc. But if the people you're building it for make baseball bats... then you built the wrong thing. Even if the data is clean, it doesn't help your users make better decisions to improve their business. And at the end of the day, quality data is data that lets you make better quality decisions.
That's a somewhat contrived and silly example, but you see versions of that sort of thing all the time. You could imagine having an initial meeting with your client and talking about the business they're in, making the observation that baseball games can only be played in good weather and then going off and building an awesome weather data system. Interesting, maybe even helpful to a related business like a baseball team, but not helpful to your client the baseball bat manufacturer.
Now, if you happen to know a something about baseball, this is an obvious and trivial error. But often times when you're building an application you're building it for a group of users whose business or use case you don't know all that well, if at all. And it's all too easy to make a relatively simple mistake like the one above and build something that is completely beside the point.
6. Use the time you save to talk to your users
So how do you avoid making this mistake?
You talk to your users. A lot. Like, all the time. You show them what you're building while it's in process to make sure that you're aligned with their needs, and you keep showing them work in process until you deliver something they think is great. It's not rocket surgery, but it can be surprisingly difficult to do. There's even a whole project management philosophy, Agile, that puts this process at the forefront.
I'm not going to tell you that Agile is perfect. There are drawbacks to any approach. And Agile, just like all other management techniques, too often decays into cargo cultism because that's easier than actually doing the damn thing.
Regardless of how you implement it, talking to your users/customers while you're working on what you're building for them is the best way (though it's not foolproof) to build something they want.
Clearly, people aren't thinking of this when they're building IoT applications. If they were, the success rate would be higher than 25 (or 15!) percent. So why aren't they doing it?
Remember the main difficulties with IoT from the Cisco survey above? No? Ok, here they are again:
- (Too much) time to completion
- (Lack of) internal expertise
- IoT integration (is too hard)
- Budget overruns
- (Low) quality of data
We've covered low quality of data a.k.a. building the wrong thing, but what about the other items on this list?
All of these other items are symptoms of too little Conceptual Compression and too much work on the widget machine. Since I'm trying to stand on the shoulders of giants as much as possible with this post, I'll turn to the incomparable @internetofshit to give an example of what I mean:
There's just a ton of complexity in that diagram. And, it's hard to imagine a single developer being able to really understand how all of the elements in that architecture work. So, you need a team, and probably a big team if you want to understand it and optimize it for your use case.
And, its all too easy to spend so much time and effort on making the plumbing of your application work, that it leaves little or no time to talk to your users and find out whether you're building a weather system for a baseball bat company, or not.
But, that's not really the worst part.
The worst part is that as you scale your team to deal with the complexity of your platform you need to change the way your team works in a way that makes it structurally impossible (or at least very difficult) to adjust what you're building to what your users want you to build.
The thing about computers is that they're dumb. Really dumb.
And the way in which computers are dumb is that you as a developer have to be really super explicit about what you want them to do when you program them. The computer never fills in the details, at least not ever in a helpful way, and you just can't rely on the sort of context clues that we rely on all the time when we talk with people.
7. Take advantage of your small team to be responsive
Context is super important and powerful when it comes to communication.
Different ways you communicate with other people have different amounts of bandwidth associated with them and the difference is almost entirely due to context.
Ranked from high bandwidth to low:
- Talking in person
- Video conferencing
- Talking on the phone
What's common among all of these mediums is the words you use. You can use exactly the same words to talk with someone, video conference with them, talk on the phone and write in an email, but the amount of information that comes through to the other person will be vastly different.
The problem is that in general the scalability of these methods of communication are inversely related to their bandwidth:
Ranked from high scalability to low:
- Talking on the phone (conference call)
- Video conferencing
- Talking in person
Now you might quibble and say "but I can broadcast myself on video to millions or billions of people around the world, that's super scalable". And I'd say "hey, this is my blog post, sit down and don't forget to tip your waitress" and then I'd remind you that I'm writing here about two-way communication, not broadcast.
The reason I'm writing about two-way communication is that's what you'll be doing when you talk with your users and customers. Ultimately, the wants communicated in those conversations are what need to get transformed into a product that your users and customers love. And, if you could just tell your computers to just have a conversation with your users and code up what they want, then we'd all be on easy street.
But, of course, you can't do that. Instead, it's up to you and your team to translate your users' wants into code that your systems can run.
If you have a small team of one, two or three people, then it's easy for the whole team to have a high-bandwidth in person conversation with a user and translate the conversation directly into code.
On the other hand, if you have a large team, then it's often quite difficult for your whole team to communicate in person with your users. In that situation, you usually appoint one or a few member(s) of the team to be the product architect(s) and have her create specification documents for the rest of the team to follow as they implement their pieces of the system. This is fine as far as it goes, but it becomes extremely challenging if your picture of what the user wants is shifting over time.
If your picture of what you're building shifts over time, and you can't meet with your user as a team, then you're in for a lot of time and expense to shift the specifications and the architecture of your application to align with the new understanding. Said another way, as your understanding of what the user wants changes, your architects have a large amount of work to do translating what they hear in a high-bandwidth conversation into low bandwidth documents that scale to meet the communication needs of a large team.
So why not just get it right the first time? Because your users don't want to tell you that you've got an ugly baby. In general, people try to be polite. So if you go to a user and you tell them about something you're building, they'll often say "sounds great", no matter what they really think. And often your users will just blithely assume that what you're building is exactly what they want, without actively listening to what you're actually saying it is that you're building.
The net result of this dynamic is that in most cases you can't describe what you're building to a user in order to get feedback that you can actually use. You have to show them something. And even then, when they're engaging with a real prototype, they may be too polite to really tell you. But if you don't show them what you're working on, you'll almost never get to hear more about what they really want.
So you've built a prototype, and you've shown it to your user, and you've gotten useful feedback. Achievement unlocked! And now you need to incorporate that feedback into the next iteration of your development. If you're lucky enough to be working with a small team, then your team can pretty much get right to coding. They've all got the full, high bandwidth context in their heads, and can start translating that into code that the dumb computer can actually act on.
But if you have a large team, then your architect needs to spend a bunch of time translating what the user said into a new set of specifications and then bring the team up to speed on what they need to know to start using them. And, if the user's feedback requires a fundamental change in the application's architecture then the big team is really in trouble.
Interestingly, this isn't because such a change is technically challenging per se. Rather, it has to do with something called Conway's Law. In plain English, Conway's Law says that the structure of an application mirrors the organizational chart of the engineering team assigned to build the application. As Eric Raymond once put it "if you have four groups working on a compiler, you'll get a 4-pass compiler."
Al Shalloway's corollary to Conway's law is really what concerns us here. This corollary states: "when development groups change how their development staff is organized, their current application structure will work against them."
What this means is that if the architecture of your application gets out of sync with the architecture of your org chart, your development effort is likely in serious trouble. But that's exactly the sort of thing that is likely to happen if you're running a big team and trying to reshape the contours of your application in response to continuous user feedback. The requirements change, the goalposts shift. And this is an essential part of the process! But it's not something that big teams are well adapted to because of the communication overhead and because of the implication of Conway's Law.
Incidentally, these dynamics are one reason why big companies can find it difficult to innovate. If you're trying to build a new thing, that's when you most need user feedback to find your way. And that's when small agile teams are at their most advantaged relative to big teams. But, big companies often, quite rightly, think innovation is a top priority for them. And, in their big company way, assign lots of resources to deal with the issue, which often attracts a big team.
Note though, that the same dynamics apply just as much to small companies as to big ones. Big companies can get great results if they scale development efforts to be aligned with the need to be responsive to user input. And that means that big companies, just like little ones, benefit from Conceptual Compression and homesteading platforms.
8. Use the freedom of not caring about things that don't matter (yet) to be more productive
So what is Conceptual Compression really all about? And, what mindset do you need to bring to the table? One of the very best distillations I've found comes from the Rails Doctrine, a manifesto of sorts that describes the mission of the Ruby on Rails web framework. Below, I've shamelessly adopted (stolen) the parts that I find most compelling to be the heart of what we're trying to do here at Apiotics.
First: You’re not a beautiful and unique snowflake.
By giving up vain individuality, you can leapfrog the toils of mundane decisions, and make faster progress in areas that really matter. Who cares what protocol your devices use to connect to the cloud? Does it really matter whether it's MQTT, XMPP, AMQP, HTTP or HELP? (I might have made that last one up.) Is this a decision that’s worthy of recurrent deliberation? No. And this is actually one of the more high profile decisions that you might make as you're fine tuning your widget maker.
Apiotics' mission is to swing its machete at the thick, and ever growing, jungle of recurring decisions that face developers creating information systems for the Internet of Things. There are thousands of such decisions that just need to be made once, and if someone else can do it for you, all the better.
But beyond the productivity gains for experts, conventions also lower the barriers of entry for beginners. There are so many conventions in Apiotics that a beginner doesn’t even need to know about, but can just benefit from in ignorance. It’s possible to create great applications without knowing why everything is the way it is.
Second: Value integrated systems.
Apiotics is about making integrated IoT systems. A whole system that addresses an entire problem. That means we concern ourselves with everything from live updating device information on your webpage without a page refresh, to helping you use prototype device hardware that one of our contract manufacturers can most easily productize and build millions of units based on.
Apiotics specifically seeks to equip generalist individuals to make these full systems. Its purpose is not to segregate specialists into small niches and then require whole teams of such in order to build anything of enduring value.
It is this focus on empowering the individual that points to the integrated system. It’s in the integrated system we can cut out many needless abstractions and reduce the duplication between layers.
9. Resist the fear, uncertainty and doubt that will come your way
Now that I've gotten this out there, I can feel all of the embedded developers rising as one to shout at me, "we've been building IoT device firmware for years, it works well, why are you fixing something that isn't broken?!?"
Well, it is broken for all the reasons I've stated above, though it is also the process people have today.
Apiotics is in the first instance a platform for web developers. And in our first release, a platform for Ruby on Rails developers specifically (but we'll be adding support for more web frameworks). Embedded developers have a critical role to play, which I will come back to. But, the developer we want to empower to make an integrated IoT system using Apiotics is a web developer.
Why web developers? Well, because many web developers already have the mind set that we think is so valuable: building things people want means rapidly building versions of the product to show to users, incorporating user feedback and repeating that process until you have a fully baked product.
Also, web developers already have powerful frameworks (like Rails) that provide enough Conceptual Compression for building web applications that a single developer can build one quickly. Our task is to add on to that foundation to let a single developer build a web application that interacts with custom IoT devices quickly. Still a significant task, but one that is much easier than it would be if these web frameworks did not exist.
Finally, we think that in most cases, the vast bulk of the unique business logic for an IoT application belongs in the web application. There are certainly exceptions and cases where putting rich logic into a device or a gateway makes good sense. But we believe that the right approach is to treat these exceptional cases as exceptions, and to focus a developer's on the right task: the unique business logic, in the right place: the web application.
If, after all this, you're curious about how we do this (and I hope you are) we've got a set of video tutorials on our site showing a web developer building a simple but full end to end IoT application in 3 minutes (and then again more slowly in about 30 minutes).
If you watch these videos, one thing that I think stands out is all of the code that you don't have to write and the pieces of the puzzle that you don't have to concern yourself with. With Apiotics, you really can just focus on your business logic and not worry about understanding or implementing the rest.
Many times developers (particularly those of the experienced and perhaps somewhat grizzled variety) will harrumph that you can't expect to rely on code that you didn't write. Now, these developers are overlooking, I believe, the benefits of Conceptual Compression. But, they're also making a different but important mistake.
Code is a liability.
The features of your application and the benefits that they can provide to your users are real and important assets. Many great companies have been built on the strength of such assets. But the code that implements them is a liability. Code needs to be implemented, tested, deployed, monitored, patched, version controlled, maintained, documented and finally retired. That's a lot of cost and headache. But do you know what code doesn't need any of that?
The code you don't write.
Getting functionality your users want without writing code is about the closest thing to free money that we've got in technology. Perhaps the cryptocurrency people will disagree with me on this point. So we'll say that it's at least one of the two closest things to free money in technology. And this one won't bring the SEC knocking on your door.
And now I know that the embedded developers are at the point of breaking down the last gate in the fortress screaming "look this all sounds great, but pointers are real. They’re what the hardware understands. Somebody has to deal with them."
And this is very true.
So our approach to this is to encapsulate the parts of the system that interact with IoT device hardware into drivers. If you are an embedded developer, you can develop drivers for IoT hardware and either give them away or sell them through our portal to the web developers building applications. That way you can, as an embedded developer, focus on what you do better than anyone else, which is writing software that runs directly on the IoT device hardware. And the web developers can select the drivers they need for the devices they want and build their applications on top.
And the way Apiotics has done this, embedded developers don't need to know anything about the particulars of the web applications that use their drivers or about the network between the devices and the web application. They can just focus on supporting the hardware. So, we're bringing Conceptual Compression to bear for the embedded folks as well.
Some of the people who have stayed with me this far (thank you) might be hardware people. People who don't hesitate to gin up a new circuit board and who know that real engineers use soldering irons. And if you are a hardware person you might at this point be ready to throw your tomato at the stage saying:
"Now that you software people have finished nattering on about whatever you software people natter on about, you're missing the main point. And the main point is that you can't possibly expect to optimize the cost of your IoT device if you don't make a careful analysis of the tradeoffs of each component of your bill of materials. And if you're going to ship millions of these things, you damn well better do that analysis if you don't want your financial people to hunt you down with a sharp stick."
To which I say, it's a fair point as far as it goes.
10. Optimize later
But, remember our homesteader? Way back at the beginning?
Did you notice that there are actually two houses in this picture? The one on the left is a sod house, which is a house that is quite literally made from prairie grass. Typically homesteaders built sod houses as their first house and then later built wood frame houses like the one on the right. This picture captures a homestead with both structures in place.
Now a sod house isn't nearly as nice as a wood frame house. They're damp, require frequent maintenance and don't like getting rained on, which is problematic for a house.
But, they are much quicker to build than a wood frame house and can be built by a single homesteader with simple tools. The great virtue of the sod house is that a homesteader can build it fast and live in it while figuring out whether their homestead would actually make it as a working farm. For a homesteader, building a wood frame house first is a great example of optimizing the widget maker rather than focusing on what matters: getting the farm up and running.
Eventually, if the farm works out, then of course there comes a time to optimize. It's the same for the IoT. The best thing to do is to get your application and its devices out there quickly and with minimal development cost to see if the market you're going after is a real one. Then, if it is, you can always squeeze cost out of your device later, and keep running your Apiotics enabled application on top of it.
11. Head West
So that's what we're about at Apiotics. Our mission is to transform the IoT frontier into an environment that any homesteader can build a great application, driver, or business in. We've built some really great tools to help you bring these principles to bear on your next IoT project. I hope you like them.
But even more than that, I hope to see you on the trail, heading West.
- Mac Dougherty