I would recommend to keep working on this. I'm interested in this space, and also contributing. Are you looking for collaborators? I think if you continue to iterate on this, there will be value, because these problems do need to be solved.
I would also recommend to create Standards for the new Protocols you are developing. Protocols need standards, so that others can do their own implementations of the protocol. If you have a Standard, someone else could be building in a completely different language (like rust or go), and not use any SDK you provide, but still be interoperable with your AAP and AIP implementation for smoltbot. (because both support the Standards of the AAP and AIP Protocols).
I also want to note, you cannot trust that the LLM Model will do what your instructions say. The moment they fall victim to a prompt injection or confused deputy attack, all bets are off the table. These are the same as soft instruction sets, which are more like advice or guidance, not a control or gate. To be able to provide true controls and gates, they must be external, authoratative, and enforced below the decision layer.
I don't view freemium as a business model, I view it as a distribution model. The distribution model changed from paid to free. This usually results in a user base that grows faster but pays less. By making the app free you've set an expectation of not having to pay. This attracts a certain type of customer, which are usually much harder to convert. If you're trying to build traction for investors this might not matter. If you are trying to monetize then this does matter.
The business model changed from a one time purchase model to a micro payment model. My recommendation would be to try a monthly payment model for v3. Let the users pay to access the service (setting an expectation to pay for value) but allow them to pay less than what you perceive to be the cost barrier (the amount you believe is the maximum amount they would pay to give it a try). I'm going to agree with others that you are priced too low. One of the best lessons I've learned is that it's not what you think it's worth, it's what your customer thinks it's worth.
I'm not sure about non-Engineering roles, but this somewhat reminds me of my experience interviewing with Facebook for a Network Engineer position. Traditionally, Network Engineers are experienced with Vendor provided solutions (Juniper, Cisco, etc) and most interviews would cover experience implementing/supporting different types of architecture using these Vendor provided solutions. Facebook Engineering exemplified a refreshing new approach where Network Engineers are also Software Developers, and the focus/goal is to proactively correct and automate Network Engineer tasks. This means there is less time fighting fires, and more time building solutions. I found this to be an interesting new approach (for me anyway). So conceptually, I could see this working; an HR person that can write the company HR tools, marketing and sales people that write their own tools, etc.
It does not matter what platform you choose (web or mobile), bad developers develop bad software. For every horribly designed, slow, bloated website you find, you can likely find a similar horribly designed, slow, bloated native app. I'm sure you've heard of garbage in garbage out. I view development as a craft and like most crafts, not everyone has the same level of skill. This does not reflect on the platform people choose. It reflects on the people themselves, their time investment, work ethic, priorities, approach, methodologies, etc. Like with most crafts, there is usually more than one way to accomplish something; some more eloquent than others. At a very basic level, both web and native apps share many commonalities; some sort of UI being rendered and interactions with data via API calls. As long as you can reach your goal, does it really matter how you got there? How about this; the debate is ridiculous. They both rock (or suck depending on your perspective).
In my opinion, the best way to promote your app is with word of mouth advertising. Unlike other forms of advertising, you can't buy word of mouth advertising; instead you need to build something that solves real problems and creates true value for your customer. The bigger problem you solve, the more value you have. A high perception of value builds loyalty, and lays the groundwork for customer advocates (which are your most important customers). When your customer talks with other potential customers that have the same problems, your app or service becomes a potential solution. Word of mouth advertising is powerful because recommendations from friends and peers carry more value than traditional advertising. Potential customers are more likely to try your app or service when it's been recommended by friends or peers. This is most effective when it occurs naturally (not forced). These are lessons learned from my first startup (results of our product, customer reactions, customer surveys, etc)
I agree; I think the concept has potential, but it was never executed properly. So it's still kind of vague in terms of what the value might be. I also agree with the comment about context. Hit the nail on the head. Without context, it just becomes useless noise, no longer any value.
I disagree; I think it's a great idea that has (still) never been realized. The implication of Ambient Social Discovery is real-life interactions. It is an online to offline transition of Social Media. Traditional Social Media has created somewhat of a Social Oxymoron; People sitting next to each other staring at their phones to satisfy Social wants and needs. Ambient Social Discovery has the implication of connecting people sitting next to each other, put the phones away, and have the opportunity to satisfy Social wants and needs in person, in real life. This is why I disagree with the 'stupid idea' comment; In my opinion, this is a literal example of leveraging Technology to increase real life capabilities (in this case, enhanced Social awareness and knowledge). The reason it didn't work is because it was not executed properly. It did not provide value. It creeped people out
Disclaimer: I bootstapped a competitor to Sonar, Highlight, and Glancee during this time period, but we never made it to Launch (problems with execution). My opinions above are based on all the (exhaustive) customer validation work that was performed.
My own personal opinion; The concept of Ambient Social Discovery should have been approached with more sensitivity towards the Users privacy. Lots of people were kind of creeped out by the concept; it was just too personal. Because of this, people were less likely to give it a try. I believe this placed the Ambient Social Discovery space into somewhat of a fringe Service, where technologists and early adopters were willing to give it a try because it's cool from a Technology standpoint, but your average Users wouldn't try it out unless their Friends had used it (aka it had caught real Traction, chicken and the egg). So this kind of put Sonar (and others) in a bad position because not only do they have the regular challenges that every Startup faces, they also had to deal with a negative perception of the concept in general (which was forward thinking at the time). I believe this greatly influenced the growth rate and adoption of many Ambient Social Discovery Apps/Services.
Disclaimer: I bootstapped a competitor to Sonar, Highlight, and Glancee during this time period, but we never made it to Launch (problems with execution). My opinions above are based on all the (exhaustive) customer validation work that was performed.
You're correct, but after watching the video and understanding how their network was attacked (all starting with the customer Router), I've attributed this more towards poor policy/design (which can be exploited by a large range of attackers) vice special information and/or capabilities reserved for state/country funded attackers. But even with this said, I think I get your point (I'm going off on a tangent). My opinion on the matter; All bets are off when it comes to state/country funded attackers. These are the organizations that lead me to my "nothing is ever 100% secure" conclusion. What we've seen insinuates that these level of attackers have access to information and capabilities that your average attacker probably does not have (example; vendor back-doors, compromised certs/keys, black rooms, etc). Unfortunately for us, these do a very good job subverting the current implementation of infrastructure security (which for the most part, is/was designed based on certain levels of trust that may no longer exist). I'm sure the industry will adapt and evolve (as will the attackers).
While I believe that nothing is ever 100% secure, I do think it is possible to implement a large range of security layers that protect Infrastructure from all but the most sophisticated attackers (aka state/country funded). The unfortunate truth is that different organizations put different priorities on securing their Infrastructure; Some might be great. Some might be not so great. So in my opinion, it doesn't matter if they have 1000 Engineers or 1 Engineer. If someone puts security higher on the priority list, then things will likely become more secure. The industry as a whole has always seemed to put security on the back-burner. SSL is a good example, released in 1996 (TLS in 1999), but not implemented as an industry best practice (aka standard) until about a decade later. When I watch this video of the Network Engineers (not Sysadmins) reacting to these slides, I get the feeling that security was not a priority. The huge red flag was the password (which was extremely weak, and obviously no two factor authentication), in conjunction with a poor design that would allow a customer enclave to gain access to the providers network (there should have been a DMZ and/or additional security controls). Another red flag; their reaction indicated that they would never have thought that someone would map out their Infrastructure (first slide was their Routing Topology, second was the Network Topology). So I'm guessing they are not security minded, since someone into security would have taken this into account when designing their infrastructure (aka, what data am I letting out of my network?), and expected this to happen. My summary; I see a bunch of Operations guys that got caught with their pants down (no offense intended, I've been there). There is a possibility that this could have been prevented with better policy, stricter policy enforcement, and better infrastructure design. It's also possible there are 10 other poorly implemented aspects of their infrastructure, and if someone wanted to get in, they would. And I guess this is my point; Unless you make it a priority to secure your infrastructure, it probably won't be secure.
The scenario described would indicate that there were delta's between the testing environment (where the DR strategy was tested), and the production environment. It was probably related to OS updates/changes being applied over time, resulting in a configuration that changes. I've always found it good practice to build and maintain a staging environment that mimics the production environment in all aspects. When configuration changes (aka security patch) are needed, they are tested and validated on the staging environment before they are deployed on the production environment. This gives you an opportunity to test and validate the results in a non-production (aka no rules, no SLA's) environment. Part of this involves validating that procedures such as DR will continue to work as expected on the new configuration, before it gets rolled out to production. From my experience, this methodology minimizes scenarios of unexpected behavior in the production environment (aka downtime). I would recommend this methodology (or anything similar) regardless of the OS/distribution you're using.
In an IT context, Ops refers to Operations (maintaining the operation of your IT infrastructure). If your infrastructure fails, Service(s) may be impacted (down/unavailable). Operations exists to keep the infrastructure (and resulting Services) alive and operational. A System Administrator (SysAdmin) is one of the roles (of many) in the traditional operations team. I see the traditional operations model evolving as infrastructure itself evolves. DevOps is a new operations methodology with a focus on leveraging development capabilities to simplify and automate traditional operations tasks. For example, identifying that a specific process always dies on a Server when x y and z happens, and in turn, writing a script/program to automatically restart the process when it experiences the defined behavior. Or another example, identifying that a network ACL needs to be modified when a new Server is provisioned, and in turn, writing a script/program to automatically populate the ACL when the Server is provisioned. Regarding TalentOps, seems to be a play on words to me; aka identifying other verticals of your startup staff and referring to it as <whatever>Ops as in "this person is responsible for <whatever> to operate".
The entrance to the vicious circle is the product. If you are interested in talking with investors you will need to produce a successful product. This implies two things; you've successfully built the product, and you've successfully gained traction. There are some great products/businesses out there that were started and/or built by a solo founder. But the majority of them were started by teams of people. So if you are in a situation where you feel you don't have the skill-set to execute, then you either need to increase your skill-set (wear multiple hats), or build a team of co-founders. Regardless of how you go about it, one fact remains; you must build! My advice would be to start building the product now (to whatever capacity possible). Not only will you learn more about the product as you build it, you'll have something to present if you decide to find co-founders. Another reason to build as soon as possible; Often times you'll find that what you've envisioned as the product will change over time as you learn from your customer. The sooner you start that learning process, the better. Good luck!
The first thing I would do is think about what capabilities you need in order to successfully execute the product, and equally important how you would want to distribute the product. Depending on the answers, I would then find a framework (or multiple frameworks) that facilitate the approach you want to take. This will allow you to prototype faster (and reiterate faster as you learn from your customers). This would also play in to how you approach building the back end.
From reading your replies to other comments, it sounds like you want access to a phone's local resources, and you are possibly interested in using web technologies. I would look into Apache Cordova (aka PhoneGap) or something similar (there are many). This allows you to build once with HTML/CSS/JS, and then distribute via Android/iOS and more (differentiation being each platform would need specific front end JS code to access the phone's local resources). This approach is commonly used in conjunction with a back end that accepts API Requests (aka front end makes Ajax request, back end responds with Data). I'm using this approach for one of my current projects.
You need to determine the cost per User. Different Users might represent different Usage Patterns, so I'd be looking for averages. If the Product is already in production and you have an existing user-base, this is how I'd do it; Correlate your user-base statistics (number of Users) in relation to your hosting costs at different milestones and/or points in time. This metric will give you some insight into how much it costs per User at different stages of growth. This could include the growth of the user-base as well as the growth of your Product (in terms of features and/or infrastructure changes). You would want to identify any trends and/or variations with the resulting averages over time. This will give you some data to work with in terms of making projections.
I'm working on a new App that we're hoping to launch soon. I can't talk about what it does because our application to TC Disrupt SF is still pending. 2 man team. Our front end stack is jQuery Mobile integrated with Backbone.js, wrapped with Cordova (native ios/android App). Our back end is based on Django/Tastypie (API/JSON) hosted on Heroku (probably move to AWS before launch). So far the App has near native speed; I spent a lot of time optimizing performance (both on the front end, and also relating to the API call payloads). I think we've nailed the UX, feedback has been good.
I'm a lone Designer / beginner Developer with an Infrastructure Engineering background, and I'm working on a project that I think will actually make a difference in the world. I agree with the OP's sentiment regarding the real world value of some of the Products (and relating investments) out there, but this was not the driving force behind the Project I'm working on. I recently moved to the Valley because one of my family members was given a certain amount of time to live. This has been hard on the family, especially considering how many we've lost over the past 4-5 years. Spending a large amount of time in hospitals and observing how medical technology works from an Engineering perspective has led me to some realizations (or at least hypothesis). I believe that there are opportunities in the health and healthcare industries from a technology standpoint. And I'm not implying monetary opportunities, I'm talking about opportunities to build something that can actually save lives. My Project is focused on building the technical foundation for a next-generation Emergency Room. Even without a background in medicine, it is apparent to me (likely from my background) that a large amount of inefficiencies exist relating to the interoperability of today's medical technology. The solution to this problem will represent a new approach towards utilizing medical technology, more specifically, medical data. The goal is to provide capabilities that greatly increase the awareness and effectiveness of medical staff operating a modern day Emergency Room. I'm currently communicating with medical staff from a few different Hospitals here in CA in an attempt to build a stronger Team. I'm also looking for Developers. I believe we can save lives.
To each their own I guess. I would call this the "what you don't know can't hurt you" approach. What would this threat and risk analysis be based on? Known threats? Unknown threats? How can you quantify "proper"?
In my opinion, if the threat could actually be defined, then there would be no security industry. Everyone would know the answer, and everyone would be secure. The reason this industry exists is because you cannot define the threat, it is constantly evolving. Doing nothing because it does not matter (really?), or justifying a lack of security by lowering the value of the customer's data sounds like an unprofessional approach.
I've always viewed security as a layered approach. The more layers you add, the better protected you are. I subscribe to the thought that nothing is 100% secure, so I would recommend to put as many layers as possible. In my opinion, the issue you should be concerned about is the effectiveness of whatever solutions (layers) you implement. I think it is being accepted by the industry that detection and prevention methodologies based on predefined data (signatures, rules, etc) are only as strong as said predefined data. In layman's terms, it will probably protect you from most unsophisticated attackers, but that's it. Today's most sophisticated attacks are one-off (0day) and/or custom, so they probably won't be defined. In this regard, some of the newer generation security solutions are developing / using smarter detection and protection methodologies (real time adaptive models vice defined positive and / or negative models). I don't mean to paint a negative picture, but I am trying to illustrate the importance of multiple layers. ModSecurity seems to be the preferred open source solution with a more active community than the rest. But Intel and Oracle also have some interesting solutions in this space.
Lately I've become a fan of isolating multiple environments. This way I can run different IDE environments on the same machine without conflicts or dependency problems. There are quite a few ways you could do this, ranging from entire VM's (something like virtualbox), to VM containers (something like docker), to language specific isolated environments (something like virtualenv for python or rvm for ruby), to prebuilt environments (something like bitnami). Each one has different pro's and con's (too heavy, too complex, etc) but the general idea is the same; Having the ability to build multiple isolated environments makes it easier for me to maintain those environments. It also gives me the flexibility to test different environment variables with some sort of fallback if something goes wrong. So it's something I would recommend, but YMMV. Another recommendation I would make (not software, but still a must IMO) is to install an SSD and max out the RAM. Feels like a whole new machine! Good luck and have fun.
Is the router your hardware? If the router was provided by (aka is owned by) your ISP, then I don't understand why you would expect to be able to control the firmware (it's not your hardware). From your providers perspective, this would imply that they've lost configuration management control of their hardware (not good for them). In this scenario, the simple solution is to install something downstream, for example a security appliance (firewall/vpn) or your own router with similar capabilities (use your own router as the ingress). If this is not correct, and you provided the router (ISP provides only the fiber), then you do have a valid issue. (but it could still be solved with the above solution).
Very Cool! Let me know if you'd like any help with Design. I can think of a few things that might help (both in terms of mobile/tablet UI and responsiveness). Not sure if you're looking for recommendations, but I'd add Sharing links/buttons for more Platforms than just Twitter (this is in the comments panel). Sharing to Twitter seems to be the only growth mechanic related element on the Site. Adding more links will make it easier for people to share their favorite products on more platforms, which will put you in front of more people. This will drive more traffic (and engagement) back to your Site.
I had a bad experience attempting to get a patent done for one of my previous (bootstrapped, and failed) startups. I basically paid a lot of money for a document that did not properly describe what we were building, and no claims. Granted, I must accept the fault, since my results indicated that I could not properly articulate what we were building (even though it seemed pretty straightforward to me). So I realized there is a problem with this; Nobody else knows the details of what you're building better than you do. So even if you do seek professional help, be prepared to properly document and explain in extreme detail what you are building. With my experience, I ended up getting motivated to learn more about doing it myself. I called the USPTO relentlessly to learn everything about the process. They won't give you legal advice pertaining to the patent, but they will help you with process and fee's. Then I started reading relevant patents for fun, and learned about the structure of the document, and what some of the requirements are. In my opinion the hardest part about writing a patent, and the most important, is the claim(s) section. It is my own personal belief (and some may disagree) that it's completely acceptable for an entrepreneur to write the technical portion of the document (with drawings). Similar to answering the Y-Combinator Application, I find it to be a good exercise in validating how well you know your own product. With the technical portion completed, then I would approach the professionals to write the claims. You can file a provisional patent yourself for under $200 (more for fast track). You can also revise it, and/or add claim(s) at a later date. Depending on what resources you have available, this might be your only option. But the general rule still applies; you usually get what you pay for. So it is definitely recommended to seek professional help. Especially considering the implications of the claims and wording later on down the road when you (possibly) run into a situation where it needs to be used (perhaps defensively, perhaps offensively).
I call it Namestorming (play on Brainstorming). I'll come up with some key words that convey what the product does in 1 word. These will be the root words. Then I'll look up all the synonyms, and any related prefixes or suffixes. I'll put them all in a spreadsheet and try them in different combinations until I come up with some cool ones. Then I'll do a trademark search on the USPTO to make sure it's not already trademarked. Then I'll do a Google search on the name, and see if anything comes up. Then I'll search for the Domain and see if it's available. If it's a Web based product, a service, or something tangible, then I consider the .com is essential. If it's an App based product, then I'm ok with other domains, especially ones that play into the word (for example, one of my unbuilt projects is named infostre.am). Then I'll do a search in the App Store(s) and make sure it's not in use (previous example is in use in the UK, but not in the US). The last test I do is to ask 10 people if they can spell it just based on saying the word verbally. If more than 75% of the people spell it wrong, or everyone spells it different, then that's no good. About 99% of the time, one of the above will fail, and I'll toss the name and start over (usually its the .com domain squatters that ruin it).
Every design I do is different, so I wouldn't have any specific rule of thumb. But there are some common things I do related to the process of designing; I guess you could call it my own personal best practices. The first thing I'll do is start with colors, and come up with 4-5 different colors that compliment each other and convey some sort of theme or feel. Once I have that down, then I get into the graphic design and create a logo. Once that's created I'll start to do the general layout for the website. The first part I work on is the UI and navigation. I'll usually storyboard all the pages of the site, and come up with what I call a navigation strategy. This will allow me to determine what type of UI and navigation elements I'll be using for each type of device. This gives me an opportunity to ensure that the navigation experience will be consistent across multiple devices. Once this is known, I'll decide on what frameworks I might use (if any) to help prototype the design faster. In some instances, and depending on what the website will be doing, I might combine multiple frameworks and use custom builds of each one as not to overlap. This allows me to pick and choose what parts of each framework will compliment what I'm building. So for example, if I'm designing for a Phonegap App or Web App, then I'll use certain frameworks. If it's for a Blog or Website then I might use other ones. Once that is decided, then I'll move on to building. Make sure you put lots of comments. I use my own custom set of css media queries that allow me to do specific designs for every major device in both portrait and landscape views. I always start with the tablet's (design for tablet first). I'll usually start with portrait, and then move on to landscape. Once the tablet view is done, then I move on to Mobile (also portrait first, landscape second). The last view I work on is the Desktop view, with 1366px wide being the most common resolution. But I also make sure it works well on 1920px+ wide resolutions. Using the css media queries, I can do this multi-view prototyping using the same files, usually using Firefox Responsive Design View to change the resolutions and orientations. If the html syntax needs to change for different views, then I'll use the media queries to control that as well. This allows me to prototype pretty fast for mobile, tablet, and desktop. Getting it production ready requires more steps, but hopefully this helps!