This is actually one of our big advantages: by building applications on Prism, there is an inherent structure to it – it was designed to be a rapid application development tool. That doesn’t mean throwing crap at the wall in order to speed it up. We have the capability of doing this very rapidly because the environment is so rich, but it also imparts a structure so that – for long-term maintenance (whether we are doing it or your internal team is doing it) – it’s manageable. It’s not a piece of spaghetti code that someone created that – when the next developer looks at it – doesn’t make sense and requires a lot of unraveling (which is a common situation with custom development shops or individuals).
Yes. We are well-versed with both of those regulations. Specific details of compliance are often dependent on the nature of the application, but if your application needs to operate within those regulations, we have experience developing applications that do. If you give us a set of requirements that are not GDPR or CCPA compliant, and you’re okay with that, we’ll implement it that way. We’re not forcing you to be compliant. But if it’s necessary for you, we can and will accommodate that for you. We are not implying that we have some sort of “GDPR button” that we push and then we’re done. It requires custom work to make sure the application is compliant – there are fundamental things we have to take into account when designing an application – but we have done that and will do that when required. If you don’t take them into account and you don’t understand what you need to do to meet those requirements, then it can be very expensive to retrofit it later. If you do understand it and you want to be compliant, then we have the expertise. We know what to do to build it into the application from the ground-up.
Yes, under the right circumstances. We have done and will do this for the right opportunity, though it isn’t typically something we do. But we do have a handful of relationships like that and for the right opportunity, we would be open to it. It has to pass a really high bar for us to want to do that.
Yes, under the right circumstances. We have and will do this for the right opportunity, though this isn’t typical. But we have some examples of having done that and would be open to it under the right parameters.
Yes, although most of our customers don’t because they are looking for our expertise to accelerate their time to market. There is a learning curve to building an application with Prism, and we’re not really offering a drag-and-drop WYSIWYG tool here. It’s not meant for any developers to pick it up and have an IoT solution created in minutes. This was built for developers on the back-end and the UI/UX people on the front-end. So, if you have those resources on your staff, they could absolutely learn Prism, but the vast majority of our customers allow us to do it. One common trend is where customers will let us do the turn-key development of the initial product and then they will do their own ongoing maintenance and enhancement from there.
Yes. Please. You should. Absolutely. We love giving demos because our ability to help you will be self-evident. You can request your demo right here.
Yes and yes. We love a good, simple answer.
Yes, in fact we recommend it. There are usually unanswered questions at the start of a project, so this is the best way to start a project. Prism is designed to build large-scale, highly customized IoT applications. But it can also be used to do quick prototypes. And the way that you do that is you focus on the specific functionality that you’re trying to test – the questions you’re trying to answer – and you don’t worry about all the other stuff that goes into the solution. As an example, if what you need is quick data collection with some analytics, maybe some visualizations, then don’t waste your time building the entire end user provisioning system and the billing system and the user management system—don’t do any of that. That all has to come at some point, but focus on just the part that matters – the primary questions you have. In a PoC, you are not trying to make it look pretty. You’re just trying to get your questions answered quickly and easily. Prism is designed to be able to work like that.
Yes, including everything from cellular carriers to public LPWAN providers. We are already pre-integrated with all of the major carriers in this space (like AT&T, Sprint, T-Mobile, Public LPWANs, different regional LoRaWAN providers, etc).
Yes. Machine Learning is a subset of Artificial Intelligence, and Machine Learning is what people are usually talking about when they say AI. But we digress. Machine Learning has many different types of applications, and we will have a Machine Learning expert specific to your solution’s needs.
Yes. And for our customers that are bound by HIPAA, we regularly sign a Business Associate Agreement (BAA).
Well, it depends on the requirements of the project, but the overall answer is yes. They typically fall into two categories: 1) Progressive Web Application (PWA) – a web-based application that is designed to run on a phone. In some cases, this is the best solution for “mobile”. 2) A Native Application (for Android and iPhone) – this is a mobile application, proper. If a native application is required, we have that capability as well. When people think of a mobile app, they’re usually thinking of an app they can download from the App Store. But that might not always be the right answer.
Apps that run through the App Store require quite a bit of specialized programming, and the approval process can be time-consuming. If you need that, we can absolutely do that for you. If you’re not sure, we can show you the options and help you decide. Our modus operandi is not to immediately say yes just for the sake of the sale. We want to understand exactly what your business needs before we jump into development.
There absolutely are times where there are two or three companies working very closely together. This is different than when we have a point solution where we bring in outside companies with some specific expertise. This is where someone says, as an example, “I’ve already picked out my hardware design firm and they’re already halfway down the path of building the device. We need you, ObjectSpectrum, to come in and build the software and make sure the integration is going to work.” Then we are working alongside an outside company, but that’s because that is what the situation called for. So, yes. Sometimes we do, and yes – we are always open to this when that’s what is needed. And the same is true for UI stuff – where a customer was already working with a design firm that they already used for their corporate identity and they asked, “Hey, we want you to work with our design firm because they’re going to design the wireframes and do all the graphics and do all the assets – could you work with them to incorporate what they do into our solution?” and of course the answer to that is also “yes.”
Yes, and really everything we do is a white labeled solution. We aren’t in the business of selling an end-user product. Our logo doesn’t go on your solution. Everything about the look and feel, theme, styling, etc is going to be your identity – built to your specifications.
Yes, we offer an industry-leading SLA and here’s a link to it.
Yes. If the customer wants to deploy our software (Prism) on their premises or in their self-managed cloud environment, then we operate in a traditional software licensing model (like deploying Oracle in your company’s environment, for example).
Nope, you’re on your own, sucka. Okay, okay – yes, of course we do. As part of us hosting your solution for you, support for you is included within that service contract. If you are licensing our software, support is also provided as part of that licensing contract. And while those options don’t include support to your end customers, end customer support is one of the optional services you can choose (as part of our IoT as a Service offering).
Yes. This is especially true for applications that have a specific geography. This could be on a farm or in a building or on a campus where the solution is well suited for a private network and the private networks can include things like LoRaWAN as well as private LTE or even in some cases, private WiFi or Bluetooth networks. Obviously, it depends on the application, but when it makes sense, we can and do provide the network and the management of a complete network solution. There have been prospects in the past that have assumed “if I am using a public network, I’ll have to pay for it, but if I’m using a private network, it should all be free, right?” Nope. Not right at all. Think of the network as one part of your overall solution. If we use a public network, then that public network needs to provide service to you, and they will charge you some type of recurring fee to do that. If we build a private network for you, we still have to provide that service, so there’s some kind of fee whether it’s built into our monthly rate, or the fee associated with the number of devices that you have, but it’s not free. Just because it’s private does not mean there’s no cost to it. Somebody has to actually operate it. Now, typically the cost will be less for a private network than a public network, but in some cases you have to use a public network because there is no other choice.
As part of a project, yes. We do not offer these as standalone services.
Yes. In fact, that is the most typical deployment model for most customer solutions.
Yes, we do. That’s really about the device itself. So, if we had an application that had sensors for a hazardous environment, we’d have to support devices with Hazardous Area certifications. But from our perspective, it doesn’t really matter that much because Prism is not in the hazardous environment. Your solution is almost always in the cloud. The exception would be on-premise deployments or certain edge computing hardware, and of course options generally exist for those that have Hazardous Area certifications, too.
Yes. We will integrate with any normal modern API that’s available for any other third-party services. There are two directions: 1) we provide a number of different options and industry-standard protocols and APIs to allow other systems to act as data and functionality within your application, and 2) we also will integrate with any normal modern API that is available for any other third-party services. One of the things that we’ve done is we’ve pre-integrated with a number of third-party services that make it faster and easier to build a solution, including things like weather data from the national weather service or satellite imagery for mapping applications or the ability to send and receive text messages. Those are third-party services that we’ve already pre-integrated to, but hose aren’t the only ones we can integrate to. We have a very open system that allows anyone to integrate with us and we can accommodate integrating any other third-party API on an as-needed basis. We’ve just pre-integrated a bunch of stuff that’s common.
Yes, we work with other companies when the situation calls for it. One of the benefits of working with ObjectSpectrum is that we have relationships with a large number of outside companies that we’ve worked with before that have specific expertise. We know who to go to when we’re dealing with a particular thing for which we need expertise. If we need somebody on the hardware side to design a specialized antenna, we know who to go to that is an expert in antennas. If we need a graphic product logo, we know just the designer to do that. These are just resources in our Rolodex® that we have experience working with and, given all of the details of a project, we will look at those things that we know are going to be beneficial for the customer to bring in people from the outside who have specific domain expertise on certain aspects of that project.
IoT as a Service is designed to be a fully-managed way to deploy and support an IoT solution. Essentially, we handle everything (or at least as much as you want us to handle). This can include things like end-user support/helpdesk, logistics (sourcing, warehousing, order management, shipping, returns, etc.), and even product management. As a result, pricing for IoT as a Service is highly customized, based on your needs.
It depends, of course. A proof of concept can often be done in less than thirty days. Depending on the scope and complexity of a complete solution, it could run from three months to a year. While there’s no “typical application,” somewhere between three and six months is common.
It depends on the scope of the solution, of course. It’s hard to give a range, but smaller solutions that have very common functionality that are using off-the-shelf hardware (so software only), could be done for as little as $10,000. Larger, more complex solutions are obviously going to cost more (it’s rare, but they could go into the hundreds of thousands of dollars). Typically, the development cost of a solution is between $50,000 and $100,000 – just to give you a general ballpark. We’re probably not going to do anything that’s less than $10,000. The only way to know for sure what your solution would cost is for us to talk to you about your solution, so call us now, and we’ll give you a more specific answer.
Yep. Bring it on. This is actually an advantage to Prism – it was designed for that type of scale, tested for that type of scale, solid and ready to roll for whatever load you put on it. And a lot of people can’t say that. Or they can say that and then your solution will pass the demo phases, then the next phase with 100 devices out there, then even that other phase with 1,000 devices – and then fail at scale. You need to make sure whatever solution you’re building has been built with that scale in mind, and in our case ALL of our solutions were (because they’re all sitting on Prism, which was intended to support massive scale).
This is a common dilemma: a non-technical person/company trying to make a decision about what technical team to rely on for a technical purchase of any kind. We don’t have a magic bullet answer for that, but we can say that we can talk about what you’re trying to do with you and you can let us show you how our expertise translates to that. We think we can make you feel comfortable about it without having to understand all of the technical underpinnings.
Well, first of all, use us if you want to ensure it will succeed. A lot of IoT projects fail because they had wildly ambitious scopes, they had ill-defined project objectives, they were developed by people with no prior experience doing this – and these are just a few of the reasons. At the end of the day, you need a strong partner that can help you not only develop the solution you’re looking for, but also help you design and develop the requirements that make up that solution so you don’t end up as a statistic. That’s what we do with every project.
Not required, no. Typically, we sign a one-year, renewable contract. This works well for both parties. Some customers want longer contracts to lock in pricing, SLAs, or some other aspect of the service, which we are happy to accommodate.
Maybe? We have to talk to you first, of course. But, because the technology that goes into building an IoT solution has become lower cost and more accessible today, more companies could probably benefit from IoT than could have five years ago. To really know, we invite you to reach out to us and help us understand the particular problem you’re trying to solve. There is a better than probable chance that the answer to this question is yes.
Yes. When you talk about asset tracking, that’s a very generic term. One of the built-in capabilities of Prism is the underlying building blocks of asset tracking, which includes things like GPS coordinated math and mapping, visualizations, geofencing logic, etc. But the advantage of using Prism and ObjectSpectrum comes when you get past the basic idea of GPS locating and asset tracking. This is where your specific needs come into play – what exactly are you tracking? Is it outdoors, is it indoors, is it something that needs to go anywhere in the world? Is it something that only moves around in a campus or a factory? Are you keeping track of more than just its location? Do you want to know information from other sensor inputs on it with data that needs to be tracked and reported? When you get into the specifics of an asset tracking application, that’s usually where we have a big advantage that we can bring to the table, because we are certainly more than just an asset tracking solution.
Our standard cloud infrastructure provider is Amazon Web Services. We’ve used them since the beginning, we have experience with them since they started back in 2007, and we like them a lot. But – we are completely cloud-agnostic. If you wanted a dedicated cloud environment as opposed to running your solution in our shared tenant cloud environment on Amazon, we can run on any cloud infrastructure provider that offers Linux virtual machines. And that includes physical infrastructure providers, too.
No problem.
No problem. The Prism platform was designed from the ground-up for different languages and for full internationalization – including the same application having multi-language support.
Lucky for you, we have an entire section that addresses this. But just because it isn’t listed there doesn’t mean we wouldn’t or couldn’t do it. We work with IoT, not a specific industry. If you need IoT and you’re in a different industry than what we have listed, you need us. Cause you need IoT.
The bulk of our customers are Original Equipment Manufacturer (OEM) companies that are 1) looking to bring a new product/service to the market or 2) want to add IoT capabilities to an existing product or service that they already offer. These are typically mid-size and larger companies, and sometimes “well-funded” start-ups.
A secondary category making up a smaller portion of our customers are enterprise companies that are big enough to justify the cost of custom-developed solutions for their own use.
All development work is broken into phases on progress payments. We aren’t asking anyone to pay for 100% of the solution upfront. That helps ensure you don’t pay for too much before you see the progress being made. You are under no obligation to continue to the next phase if you are not satisfied with our work.
Whether we host the application or you do, there is an operating cost which includes computer equipment, services, connectivity, support, updates, security patches, maintenance, backups, etc. After all, servers require care and feeding. That cost is part of it, and this is one of the benefits of, and why most of our customers prefer, that we host the application—so that the costs of that can be very well understood and the economy of scale comes into play because we’re not just doing this for you, but we’re doing it for all of our customers. This is why hosted services and Software as a Service (SaaS) is as popular as it is—there’s a real advantage to doing it this way. We didn’t invent this idea, but it’s usually the best solution. But, if you choose to do it yourself, you have to be realistic about what those costs are. There are both recurring technical costs and there are manpower costs to hosting and managing an application. Especially something that needs to be online 24/7. So that’s obvious.
The other part is support for the end-users of the application and maybe (depending on the nature of the app) dealing with sourcing or manufacturing, provisioning, and shipping of devices, dealing with customer service issues, returns, replacements—just all the normal logistics. That’s going to vary based on the nature of the application, but that is definitely an ongoing cost. Some companies choose to do this themselves, while others prefer to let us handle the whole thing for them—this is what we call IoT as a Service.
The last category is that there are almost always additional enhancements and normal maintenance of the software that went into the solution. It’s very rare, if ever, that you have an IoT solution that is never updated or has a feature added or some other sort of enhancement that goes into it. So you should always budget for future features, enhancements, and maintenance of your application. This is a case where most of our customers will have some combination of a fixed monthly budget of development hours that we have and we just chip away at a list of features and enhancements they want over time, and/or they’ll have new milestones where they say, “okay, we’re going to add these 20 features,” and then it’s just a new development project with an estimated cost like the original development project.
So, in summary:
What pricing model do you use for your IoT solutions?
Well, first let’s exclude IoT as a Service in this answer. It’s not a requirement in our solutions, and it is priced based on what you want us to do for you. If you’d like to understand IoT as a Service pricing, click here.
There are two different pricing models for our IoT solution projects:
As mentioned, the most common pricing model is that we host it and manage the solution we build with you (#1 above) because it’s the most economical, the easiest to get started, it doesn’t require any technical expertise on your part, doesn’t require any personnel on your part, and it’s a turn-key service that grows with you. You also never have to worry about back-ups, servers, security patches, and so much more.
A Note on Pricing Models in General: there will typically be ongoing software development (for updates, features, etc.) that continues after any solution is deployed. This is normally billed on an hourly basis where you are buying blocks of hours. There are two ways to structure the fees for ongoing development: 1) as a monthly budget, like a retainer, or 2) as a subsequent, clearly-defined project.
Consulting, Design (product, software, firmware, application, UI/UX), Development (software, firmware), Application Management (hosting your IoT solution, the ongoing management of it, supporting software services). To that last point, when we host someone’s IoT application, it’s not like we have one server hosting that IoT application. It runs across many different servers and uses many other servers that provide services (like everything from email to text messaging, to message brokering to database, etc.) so it’s a big environment that has dozens of servers that are all there to support your application. We also provide something we call IoT as a Service, which is a full turn-key outsourcing of the ongoing operations of an IoT deployment, providing as much or as little of the ongoing operations as you like.
In most cases, what we’re looking for from the customer is somebody that has expertise in the subject matter – someone with domain expertise in the area of whatever the solution is. If it’s a solution for ranchers, we need someone with deep ranching expertise.
You do. When we build it, we will use both third-party software and our own software (Prism) as part of building the solution. Those third-party pieces might be open-source, or they might be commercially licensed (and of course we’ll let you know what tools we’re using), but the application that ObjectSpectrum builds to your specs belongs to you, the customer.
You, the customer, do.
See the FAQ titled, “Why use you instead of a custom software or an internet application development firm?” It’s the same answer, just replace “software outsourcing firm” with “web development firm.”
But specific to this question: what they’re doing in a very complex web application project is just very, very different from an IoT project. It’s not what they do. We aren’t saying it is impossible for someone that has web design and e-commerce experience to also have IoT experience, but it’s highly unlikely that their IoT experience would be very deep or wide. The vast majority of companies that specialize in web, e-commerce, and mobile applications simply have not had the exposure to a true IoT application. This is also part of the challenge: the term “IoT” can be used very broadly. Somebody might say, “I wrote an app that lets someone see the pollen count in their zip code and that’s an IoT application.” No, that’s a mobile app. There’s no IoT there whatsoever, but someone will tell you the opposite when trying to sell you on using them. It really does boil down to expertise.
We aren’t saying it isn’t possible, but we are saying it’s unlikely they have the expertise because, frankly, it’s just a different skill set. You can be an amazing musician and know how to play the trumpet, the trombone, the tuba, the French horn and all other brass instruments, but that doesn’t mean – with all the expertise in the world as a musician – you will be an expert at the viola. In fact, odds are, you won’t have a clue about playing the viola. You wouldn’t go to the foremost musical expert in the world who plays brass instruments and expect her to teach you about string instruments. And yet, we see that happen frequently – especially when that company is not terribly technical. They ask themselves, “who do we know that’s technical – oh yeah – we should call the company that built our website. That was technical!” It’s the only technical company they know. And then they call that company and say they want to build this application with all these sensors, etc and the sales guy is like, “Oh heck yeah, we can do that!” – ‘cause they’ll say yes to anything – and then two years later they’ve spent five times their initial budget and they won’t have anything that actually works. This happens literally all the time. If someone came to us and asked us to build an e-commerce system, we’d simply say “no.” And that’s not because we don’t have some idea about how e-commerce works. It’s because we focus on IoT. That is our expertise–the many complex layers of IoT–and that’s what we do. That’s all we do.
There are two issues here:
It ultimately translates into speed, cost, and low risk. That’s really what this boils down to.
ObjectSpectrum is primarily a software engineering company, focused on creating IoT solutions. We are more like a traditional software outsourcing company than a SaaS provider. An IoT SaaS company is primarily looking for a customer that wants to do it themselves and is willing to operate within the constraints of their software. The closer you get to a tool that can be used by non-software engineers (i.e. application designers and developers), the more you will have to play by the rules they have created in their software. Their software will let you take your knowledge of your warehouse, for example, and combine that with their software to connect and monitor this thing and that thing, and that’s great. But by targeting that kind of a user, you are going to be putting constraints around what you can do. And for some people, this may be completely fine. That might be the best choice for them and their situation.
If you are an enterprise customer, and what you need is to collect data from a hundred different sensors in your factory, or GPS trackers on your hundred different pieces of heavy equipment, then an IoT SaaS company could be okay for you because it will let you build a functional application. But the problem is that you are still going to be working within those constraints. To be clear, we are not knocking the idea of you working with an IoT SaaS company. We are just stating what’s different about that type of company and ObjectSpectrum. It’s important for you to understand the differences so that you can make the best choice for your specific situation.
But the dirty little secret of any SaaS company is that if you need to go beyond the scope of capability that they deliver to you, you either a) have no choice because they didn’t provide you with a way to extend it, or b) you now need to bring in the hardcore developers that are necessary to go beyond that set of functionality provided with the software. If you’re trying to build an application that is going to be offered for sale, either as a standalone service or as part of something that you’re selling, you want something that is a lot closer to from-scratch software development. You want something that doesn’t have those constraints; you need something that isn’t designed for a non-technical user. Because you’re going to run into issues with the SaaS products where they simply don’t meet your needs, and then what do you do? So the target audience for this is typically someone who is using it internally and they’ll tell you, “oh no, you can white label it, put your logo on it and offer it to your customers,” and that’s all great. If what you actually need is what they thought you needed, you’re in good shape. But as soon as you cross that line, you’re now into having to bring in the technical people to actually get the job done.
The bottom line is that an IoT SaaS company is not in the business of IoT solutions engineering. It is in the business of licensing a piece of software. ObjectSpectrum is in the business of solutions engineering. Tools like an IoT SaaS company can be a great prototyping tool. Because once you learn how to use their tool, it can be very quick and easy to set up, “okay, we need to monitor these five sensors and we need to test this thing over the next two weeks” and that type of stuff. It can be a great prototyping tool. Unfortunately, with most IoT SaaS companies, it comes with a pretty high price tag just to license it. So that makes it kind of an expensive prototyping tool. That’s not the case for every single one of them (IoT SaaS companies), but it is with a lot of them.
Well, does your internal team have this skill set? Are they deeply experienced in IoT design and development? Maybe they’ve been doing database development for your ERP system. Are they the best people to develop an IoT application that they themselves know nothing about it? Of course not. But okay, let’s presume your internal development team does have the skillset. But then we’d ask why not let us work with your internal development team? Let us be the expertise in the IoT side of this and let your internal team be the experts in your business. And, under the right circumstances, eventually your internal development team could take all of it over. We’re using all kinds of industry-standard tools and languages and protocols. It’s not that someone couldn’t learn it, it’s just do you want to pay for your internal team to go through that learning curve? We can short circuit that process and then you always have the option of letting your internal team take over maintenance and future development.