I've been the sole developer of several startups over the years and still am for some. Some suggestions:
- If there's no unequal investment in the startup (like for example someone putting in a lot of money or more time compared to others) ownership should be split equally amongst the founders. Working remotely is a nonsense argument for getting less equity, not giving everyone the same will most likely end up in conflicts later on.
- Make sure you have your equity on paper and come up with a vesting scheme so no co-founder can walk out with 33% after a couple of months while the others have to carry on for years. (for example unlock 4% every month of work so that you only earned the complete amount after putting in at least 2 years)
- Becoming profitable and/or receiving investments can take a while, does every team member have the runway to work on this long enough to not need any income from it?
- You can't just leave like with a regular job since the future of the startup depends on what you do, keep this in mind. If you are not 100% sure you want to spend the next couple of years on this tell the co-founders beforehand that you will build the MVP and decide once that's done if you want to continue or not. A vesting scheme will make sure you at least get something out of it.
- If you complete the MVP and don't want to continue you can consider selling the MVP to your co-founders at a predefined rate in exchange for your shares. If you do this for a good price and terms and they have the funds for it this might be best for all parties since you are no longer connected to each others as shareholders, they don't have to involve you in new decisions and you don't have to free up time in the future for a company you are no longer involved in otherwise.
- You might want to wait with formalizing the shareholder deeds until a investment comes into play (this all depends on where to company is located and what the laws are of course). Do get stuff signed on paper beforehand though!
- Don't undervalue yourself, in the end YOU are building it, idea's alone are worth nothing.
- Startups are rough, prepare for a lot of fights, failure and lost free time and decide for yourself if you think this startup is worth spending a couple of years of your life on. Keep in mind that most startups fail, my personal experience is that this usually has to do with the dedication of the team doing it.
It's not about being blind to criticism, it's about lies being told about a cool new technology in a thread about a cool project build on top of it. This complete comment thread has been taken over by a discussion about IOTA, about parts of IOTA that are not very relevant to this project, and the authors comments of the project who's here as well get snowed under due to this.
It would be ideal on trinary hardware, but it can work with a trinary emulator for now. I expect to see a Trinary chip very soon. CfB, one of the core devs of IOTA, founder of NXT and inventor of PoS has a team that has been working on Jinn (trinary cpu's) for the last 6 years.
1: By using a ternary number system, the amount of devices and cycles can be reduced significantly. In contrast to two-state devices, multistate devices provide better radix economy with the option for further scaling
3: The wallet is secure and does what it needs to do, no, it's not very pretty or user friendly but it works. A new wallet (Trinity wallet) will be released very soon.
This isn't solving a problem, it's just making it a little less worse. Proof of Work by mining is just a plain stupid and wasteful idea. Ethereum is already switching to Proof of Stake which is slightly better (but it still gives the power to the biggest holders since you have more influence with more ETH, leading to more market manipulation by mining cartels).
I think a non-blockchain, Tangle based concept like IOTA uses is a way better future, better in terms of scaling (the more users the better it gets), no transaction fees and, maybe best of all, no mining/miners.
If you like the concept of scripted 3D modelling check out OpenSCAD. Instead of entering commands you create a script that build your model for you, including the option to use variables, loops and conditions to adapt your model to certain parameters. I use this for creating customisable 3D printable models and it works great if you know the basics.
It would be very cool if they will be able to do this, I've toyed around a bit with multicopters and know a thing or two about the current state of non-military UAV's, here are my thoughts:
- They use a octocopter; that's great for the payload, plus it adds some redundancy; If a motor fails the others take over to get back safely without crashing. A bad thing about this is that it's a heavy lift, so more battery drain, so it needs a bigger battery == even more drain. I think you can get 30 minutes of flight time at the max out of that, with a lot of heavy batteries.
- Multicopters carrying payloads use powerful electronic motors; You do not want to put a finger near a spinning prop, for safety reasons a UAV within reach of people or animals should always be controlled by a human, what if someone runs up to the package to pick it up and the UAV automatically spins up to return to home?
- Auto landing is possible, but might be dangerous; The current systems (for example ArduPilot) use GPS and acc/baro/gyro/compasses to achieve autonomous flight. It works if your in field without trees around you, but the system can't find the best spot to land for you, so you need to land it by hand for this delivery service, controlled by a pilot over FPV (first person, wireless video connection).
- Experimental FPV ranges over 10 miles are possible, but not fail proof, especially in a non-line of sight environment or while landing (low to the ground).
Hate it to be a nay-sayer, this will have a future but the tech isn't here yet at this moment to accomplish it fully autonomous and safe.
You are absolutely right: It's been a while since I last used Titanium. At the time you had to use a crappy/buggy UI to compile your app, with random bugs ocuring all the time, not being able to build once you've upgraded to a newer version due to backwards incompatible changes and more weird incompatibility bugs with other versions of XCode, and so on. I hated the experience since I couldn't rely on being able to building my app and Objective C library support wasn't available at the time or didn't work very well. I quitted using Titanium once they switched from their own buggy UI to Eclipse for building, my code was backwards incompatible, the UI couldn't compile to older versions of Titanium, I had enough. It's true, it has better performance as say a Phonegap, but it did have some weird layout issues from time to time which were hard to fix. Overall I think it's a nice product for creating an app without learning Objective C but I won't use it for a clients app any more, too unreliable.
Oh, and yes, it is 'cross-platform', except for the fact that there are so many things not working on Android (either bugs or non supported in the API for Android) that you need a seperate build for android to make it reasonably useful.
This is al based on my experience with Titanium Mobile from around 2 years ago, so it might be better now.
I've created native iOS apps, native Android apps, HTML5 apps and I've used wrappers (Titanium Mobile and PhoneGap) over the last few years and these are my findings:
- Native apps take a lot of time to build, especially when you are a web-developer without in-depth knowledge of the extensive frameworks available to the native platforms.
- Wrappers work, but are not nearly as great and snappy as native apps; They might contain a lot of hard to fix bugs as well and are harder to debug if they tend to crash.
- HTML5 only apps are not available in the market/store so no free advertising, you can't access things like the camera with HTML5 only, you therefore need a wrapper.
My vote goes to native development; Although it's more work and code to write it's much faster and stable if done correctly. You've got more freedom and bugs can be solved. A native app just feels right, where a HTML5 only app won't give you the best user experience you can get, no matter how much time you put into it. If you need a flexible, big, cross-platform app without a lot of budget to build at least 2 native apps a HTML5 app with wrapper would be a decent option, but for anything else (especially the more simple apps with just 2 or 3 different views) you should go with native.
A heli carrying a DSLR is big, expensive, hard to fly, dangerous and maintenance intensive. It's good for lifting a DSLR but I would go with a multicopter, the more blades the better. A hexacopter or even an octocopter are very stable, easier to fly, possibly cheaper to build and have a fail-safe, if a motor fails you can land it safely because the other motors take over. You can find a nice video about the subject here:
It demo's a Heli carying a DSLR and afterwards (after the first 7 minutes of video) they talk about this compared to multi-rotors. For the best video results you should probably pick the stable octocopter, you can fly FPV as well with a multicopter, great for live previewing your video.
Indeed, the 5c is just a bad deal; You get the iPhone 5, a model that would've been reduced in price anyway if they retained it, with no big/significant changes other than a plastic shell (downgrade if you ask me). Thats fine if they'd set the price to say $399, but at $549 you would be mad not to lay down another $100 for the 5s.
Bought the PDF beta once it was posted here on HN with the hope you guys would be nice and provide an EPUB version later on. Just want to say thank you for listening and doing so! If you haven't bought this book and are in some way (beginner or veteran) a Django developer go and buy it, there is always something new to learn even for the most experienced.
- If there's no unequal investment in the startup (like for example someone putting in a lot of money or more time compared to others) ownership should be split equally amongst the founders. Working remotely is a nonsense argument for getting less equity, not giving everyone the same will most likely end up in conflicts later on.
- Make sure you have your equity on paper and come up with a vesting scheme so no co-founder can walk out with 33% after a couple of months while the others have to carry on for years. (for example unlock 4% every month of work so that you only earned the complete amount after putting in at least 2 years)
- Becoming profitable and/or receiving investments can take a while, does every team member have the runway to work on this long enough to not need any income from it?
- You can't just leave like with a regular job since the future of the startup depends on what you do, keep this in mind. If you are not 100% sure you want to spend the next couple of years on this tell the co-founders beforehand that you will build the MVP and decide once that's done if you want to continue or not. A vesting scheme will make sure you at least get something out of it.
- If you complete the MVP and don't want to continue you can consider selling the MVP to your co-founders at a predefined rate in exchange for your shares. If you do this for a good price and terms and they have the funds for it this might be best for all parties since you are no longer connected to each others as shareholders, they don't have to involve you in new decisions and you don't have to free up time in the future for a company you are no longer involved in otherwise.
- You might want to wait with formalizing the shareholder deeds until a investment comes into play (this all depends on where to company is located and what the laws are of course). Do get stuff signed on paper beforehand though!
- Don't undervalue yourself, in the end YOU are building it, idea's alone are worth nothing.
- Startups are rough, prepare for a lot of fights, failure and lost free time and decide for yourself if you think this startup is worth spending a couple of years of your life on. Keep in mind that most startups fail, my personal experience is that this usually has to do with the dedication of the team doing it.
Good luck!