Chaos, no sleep, chaos, endless stream of changing requirements, you will be blamed for everything.<p>Just remember: the real bonuses will go to the managers, not you, they will get rid of you as soon as they will need to find someone to blame for their decisions.<p>And of course the non-technical managers will know that "everything is easy, you will do the new dropbox over the weekend, right" (however that's so easy that they cannot do it themselves).
I would make it clear for other founders that their role in the pre-product startup is to<p>1) continuously (daily) interview potential customers BEFORE the MVP is ready (and document their findings) so that you as a team have clear understanding what customers actually need<p>2) ensure enough financing that the product and team can be build<p>3) help you in recruiting more developers<p><i>Understanding customers</i><p>I once did a startup in a similar setup (2 non-technical founders, me as a single technical founder) and the biggest mistake was 2 non-technical founders were waiting for MVP to be ready before they really started to approach customers. I tried to push them to do more customer interviews, but they looked it purely from sales perspective and thought we didn't yet have anything to sell. We effectively build the wrong thing that nobody wanted and they started to lose interest when they realized that the MVP doesn't sell on it's own without significant iteration.<p><i>Hiring</i><p>Also, although building MVP quickly is an important step so that you can start to collect better customer feedback in a search for product-market fit, remember that building a team is as critical. Even if you don't have money to hire engineers at this point, you need to start to build hiring pipeline early. It is very hard as a single developer to effectively take care of both bug fixing, devops and new feature development when you start to get customers.
Well, obviously you're going to be doing all the development, testing, sysadmin and office IT work until you get more staff, at which point interviewing will take a lot of your time. You need to be adequately good at all of these.<p>Less obviously you'll be making the technical decisions, and then having to work out where responsibility for these and "product" decisions lie.<p>It's not clear where the cash is coming from; are you all paying in? Did that decide the split? Who's getting paid and who's putting in "sweat equity"? You're also a founder, right?<p>Given your position you should entrench your status ASAP as "CTO" or similar title <i>before</i> you start hiring. You should decide how you feel about people getting hired "above" you (good or bad) and plan accordingly.<p>There will be at least one stand-up shouting argument early on. This is normal, but needs to be handled maturely - done successfully it will improve the business. Being the "remote" partner puts you at a disadvantage here.
Care to give us some context?<p>Also, take the doomsayers in this thread with a grain of salt. Some developers have bad experiences in their career and start thinking that all non-technical folks are just soul-sucking vampires, while often in reality they themselves are the source of the problems.<p>I would say that your main function is to effectively communicate with the co-founders and be the bridge between technology and business goals. Make sure they're aware of pros and cons of every development related decision. Get used to saying no and pushing back on some of their ideas. Your main goal is building a successful business, writing clean code and using cool tech comes in secondary.
Everything will be your responsibility and your task. Everything will be "easy" according to non-technical people who will expect "trivial features" as seen on Gmail/Dropbox/Twitter/Linkedin.
it would be an alarm bell (big one) if none of the founders has a technical background. When you join a new group of people who you have no history with it, then it takes some time to build trust (battles fought together under which bonding can occur) and learn their motives.<p>My fav resource (only discovered it recently here on HN) is this document <a href="https://docs.google.com/document/d/1ZJZbv4J6FZ8Dnb0JuMhJxTnwl-dwqx5xl0s65DE3wO8/preview#" rel="nofollow">https://docs.google.com/document/d/1ZJZbv4J6FZ8Dnb0JuMhJxTnw...</a><p>it has helped me a great deal to assess a new situation and figure out whether the non-tech founders and decision makers in the firm are actually on the ball doing <i>their</i> part.<p>Understanding their role (what is their strategy in finding product market fit) is crucial in evaluating <i>"your bosses"</i> performance and ultimately if whether the team and product can make it post MVP.<p>Just focusing on MVP is a fallacy IMVHO because it lets them isolate you (the engineer) into sticking to your niche within the org. The problems then start once you have the MVP and <i>bosses</i> then realizes they have missed all the steps (because they didn't know and unlike you are still learning the hard way how to do things) and you as a team are actually nowhere. It always ends in tears unless all of you are already at eye-level.<p>good luck!
I've been in the same situation and here's what I learned: You will mostly never be able to revisit and refactor code 'once and for all' when it's deployed into production. The choices you make now will affect you in the future.<p>Instead your focus should be to take some time regularly and make some changes to keep your code from becoming a chaotic vengeful mess of a spaghetti bomb. The best analogy I have is something akin to gardening: it's through constant care and weeding out of bad vegetation that you have a great garden. You can't leave your code unattended and must always tend to it...
You are the doing all the work department, whilst they are head office.<p>It might not <i>be</i> like that, but it will sure as hell feel like it. When they both take an early Friday to have a meeting in the bar/home/park, and you're stuck burning hours, and the weekend, trying to make those quick changes needed before next release. They both agreed they were necessary, but they don't accept that needs a full db redesign.<p>You have everything in writing, and your respective percentage and share vesting sorted already? No? Leave now.<p>If you have 50% and they 25% each, signed off, and you thrive on stress, keep on truckin'
Be prepared to not get any credit where credit is due and to be blamed for everything.<p>This is a position I was in for my own company and I will never put myself in a position like that again.<p>I spent countless nights and 20 hour days writing code, rewriting code, deleting everything, starting over, integrating every fucking thing on the planet, removing those integrations, etc.<p>The non technical founders won’t have any sense of what it takes to do the random bs things they come up with while “at a lunch,” and will expect you to whip it up quick, oh and it’ll have to take precedence over that thing they asked you to whip up quick just yesterday.<p>When you finally decide you’ve had enough and things aren’t going anywhere and you leave for a super high paying job, they’ll turn around with claims that you never did anything and you really fucked them.<p>I know this might come off as harsh, but being the only technical person is a huge mistake. Try to get at least one more in there and REALLY push to set expectations. Be very transparent in exactly what it’ll take to do something. If you need to create a feature, let them know “sure I can do it. It’s not easy though. There are database migrations to write, the feature will need to be tied into our existing codebase. It’s currently X, but needs to be Y for this to work with it. Problems A, B, and C will probably arise and I’ll have to 1, 2, 3, ...200.”<p>Even then they’ll just be daydreaming about their next “important meeting” where they’re really just getting drunk at another lunch with someone and discussed the product in a few hushed tones before “shooting the shit.”<p>You are the backbone and the heart of this company. Don’t be afraid to speak up, and understand if you leave, they’re fucked. Don’t let them make you believe otherwise.
While the OP has said they have 20% equity. Given the other two founders have a controlling interest, to what extent could they push the OP out and take/reduce their equity?<p>I’m not saying they would, but I’m wondering how possible it is. Could they vote to redistribute equity, or massively dilute OPs equity and then distribute more equity to themselves for example?
I've done this eight years ago, delivered a prototype in Ruby on Rails with MongoDB for two educators from the mid-west. Six timezones between us and though I kept developing for them, most of the time as the sole developer, I never met them in real life. Expect the company to run out of money every now and then, be prepared and you'll be just fine. That's startup-life :)<p>Would I do this again? YES. I enjoyed having the freedom to make technical decisions from the database to the amount of tests I wrote (the app still has some 80% of its code covered, the rest is just the admin area I never cared writing tests for). We also got the product out early to customers. Make sure the decisions and implementations you do are there for the next five years. Don't attempt something stupidly new but stick to solid tech with a good ecosystem that you can rely on without having to keep track of it all the time.
Mind you, I mentally wrote off the little equity I had (the hourly rate was great) since it just didn't grow exponentially, I rather see the company around another eight years without me.<p>What I'd do differently is to set myself a target, say three years. If by then the company didn't grow as we wanted it, I'd go and try with another startup.
I have been through this (as the only tech founder in the group) three times with three different startups and found different reasons that it did not work out.<p>1. Equity. I like to think that the percentage of equity you get in relation to the amount of work you will be asked to do. 20% to do all the product (and/or service) development seems way too low for me.<p>2. In one of the startups I founded, we could not convince the non-tech CEO founder to release the MVP to early customers - even after extensive customer interviews, because the non-tech was not comfortable that it was an MVP. No desire to find the golden product/market fit and no desire to release anything less than a full blown, polished product (which we could immediately start charging for). And no funds for development either (just equity) - so entirely too much development needed to be done before any return (and no customer feedback).<p>3. And then I was in a startup that had a non-tech founder who was very weak at sales and very bad at raising money. But really good at asking for AI, VR, voice recognition, and (add buzz word here) in an MVP - entirely created and supported by a sole developer.<p>I would suggest staying away from any of the above.<p>Good Luck.
To counter lots of (possibly unfounded because too general and/or lack of actual experience) negativity here: the problems will mainly depend on the co-founders. Non-technical doesn't per se mean completely ignorant or stupid. If they are reasonable and smart, they recognize you are the one who knows the tech stuff and hence will let you take care of the technical side without much questions, let you experiment and go your own way, will value your input when it comes to decision-making on the software front, won't set insane deadlines, ...<p>Such people exist, I've worked with them, and that was all good. In the beginning it did sometimes take lengthy discussion why some features couldn't 'just' be implemnted but for the rest the main problem I had was getting into a 'me alone on an island and I'm the king' state leading to less self-critique and being stuck with old tools while better stuff is available. But nothing that cannot be fixed by keeping an open mind and reading around on the internet on the tech used.<p>Obviously if your co-founders don't quite fall in this category, yeah, running might still be the better option.
Get out, get out now.<p>> for my startup<p>It's not YOUR startup. Your startup would mean 100% of ownership.<p>(from another answer)<p>> 20% for me for now because I work remotely.<p>Do you have any documentation for this 20% stake ownership? If not, you can be replaced in an instant.<p>Are these two founders in the same country? Yes, well expect to have decisions made without your input.<p>There is also the challenge of the other founders appreciating your input into the company. You are doing everything. They won't appreciate this and they won't see the amount of work either.<p>Non-technical founders know squat and they don't care either about how much time it takes to do things.<p>------<p>I've gone through this myself. I was a "founder" in 1 startup with a non-technical founder and before that I was a "small" equity holder in another company, which was founded by 3 non-technicals.<p>In both circumstances I was just an employee doing my job. No upside at all. I didn't come away with anything but experience in the respective industry.<p>------<p>If you are going to stay, then I suggest to learn how to implement the tech for this startup and in turn, can provide you with a springboard for your own startup and if this is the case. Ensure you are getting paid!
The thing that I enjoyed being the solo developer most is that I got to make all of the software design choices. I set up the project the way I wanted to and code in way I felt would best to ship the product. Loved that aspect of it.<p>That being said I would do two things differently.
1. Be hyper about testing.
If you are the only dev working on a project test,test and test more. Write good unit tests. Have your fellow co-founders test and sign off on a feature before going to prod. If you are working hard it's easy to miss the obvious. Test it all.<p>2. Find good ways to communicate where you are and what you are doing.
Some features take longer than others. It drives non-technical people crazy (Why did this feature take an hour and this one a week?) but that is the hard fact of software dev. Use a Jira board or an email, whatever will let your co-founders know what features are where. It really saves on the annoying status update requests in person or over email that disrupt your day.
Good Luck :)
Be careful about being "typecast". You may find yourself doing work that is necessary but not something you'd want to focus on career-wise. However, everyone else may start thinking of you as the specialist for that work.<p>Example from my career - I joined a startup as a senior-level architect. There were only a few tech folks at the time and my background was databases, so I ended up doing a lot of the database work. It was something I was good at, but I considered it part of a past from which I was moving on.<p>Eventually I was typecast as an operational DBA - a tactical role rather than the strategic one I envisioned. When management decided to adjust my salary accordingly, I had to leave.<p>Lesson: Communicate to management all the technical roles that are required in your startup. Let them know which ones align with your own career path. Remind them that they eventually need to get others to fill the other roles. You will have to repeat this often, just not often enough to be a pain about it.
Unless the other two co-founders have raised a massive amount of capital for you to hire an engineering team you should probably leave immediately.<p>Everyone else commenting has brought up valid points. This is a high-risk high-stress low-reward situation for you.<p>Get out while you can. The first version of the app <i>you</i> built can serve as a great showcase in your portfolio.
You didn't say much. What kind of product? What kind of experience do you and your founders have? What are your and their personalities like?<p>The problem with startup advice is that a lot of it just doesn't apply. People make assumptions and generalizations that apply to one business space or team dynamic, and then project it onto your space and team dynamic.<p>Because of this, it's very hard to anticipate problems.<p>In my experience, I was 50-50 with someone non-technical. My biggest mistake was not walking away soon enough. The warning sign was that my co-founder let his imagination run away whenever we tried to plan anything. We could have fixed all the other "mistakes" we made otherwise. The problem was that most of our planning turned into me trying to guide my co-founder back to reality. (Edit: It took me over a year to realize that my co-founder was constantly letting his imagination run away. In hindsight, if I realized this sooner, I would have set up the arrangement very differently.)<p>IMO, it's all about everyone's attitude and product / service choice. As long as you're in a space that you're capable of working in, and everyone has the right attitude, you can learn the rest. (My co-founder, after we separated, had a lot more success once he stopped letting his imagination run away.)<p>What I can say is this: Are the people you're working with reasonable people? Reasonable doesn't mean mature, as unreasonable people are good at appearing mature. Reasonable means that, if they have an idea, they don't keep pushing when you say no.<p>Because "they" outnumber you, another thing to look for is if one team member is a mediator. They might try to mediate in situations when they should take a side. (IE, trying to mediate when someone wants to make a green line with a blue marker.) That's what I mean by confusing maturity with being reasonable.
I have been working in a startup for close to 2 yrs ,with myself being the only developer , although I have a small team trained to perform daily activities
I convinced another person to be the CEO and do the marketing, although we make only enough money to just sustain it has been a rich & different experience for a developer
In programming we get as many iterations to get our code ready, but many time we get only one chance to convince people. I will probably never be good at people management or marketing
Point is forget the money or the agreements are you convinced you are learing something new then continue ?? if your company becomes big or not people will recognize whatever you did
You don't give a lot of context, and a lot of comments here are telling you to run away.<p>My only advice: if you don't get at least 40% of equity, run away. Two "idea guys" giving barely 20% to the technical code monkey and enjoying controlling share while they can deal with "the real stuff" is a huge red flag. If they are willing to treat you as a real equal (and even more, as the guy who will actually do most of the work for at least a few months) then it's worth giving it a shot if you believe in the idea.
The most annoying part of your work will definitely be "interviewing" and Knowledge transfer sessions for the foreseeable future. Thinking about this even gives me a headache. The pros can be god mode for a long time. If you are good in your job then management will think twice to fire you. Then you'll probably be more entrepreneurial once you leave that place. Your value will be high. (Warning: These thoughts may not necessarily reflect reality.)
Well, the first question I'd ask you is ARE YOU BEING PAID IN ACTUAL LIQUID CASH? If no, jump ship now.<p>Other things include contractor or W2, the nature of your work environment, who's tools you're using to do the work, who decides salary and the method of payment, company culture, etc. In startups like this, you have a much higher risk of being scammed somehow (late paychecks, being given a 1099 when you are legally entitled to a W2, having your pay docked if your boss isn't satisfied with your work, etc) when the business starts losing any amount of money.<p>Bottom line is that you should treat this as a 3-6 month W2 gig and jump ship during that time.<p>Also, this has been said all over HN but it needs repeating, equity is essentially Monopoly money. Forget the equity and focus on finding a new job. Remember that these people shoving all this work on you are also the ones who control your ability to get paid (and, by proxy, house and feed yourself), and have the ability to "forget" to file your paycheck when times get tough.
I've been the sole developer of several startups over the years and still am for some. Some suggestions:<p>- 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.<p>- 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)<p>- 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?<p>- 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.<p>- 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.<p>- 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!<p>- Don't undervalue yourself, in the end YOU are building it, idea's alone are worth nothing.<p>- 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.<p>Good luck!
You need an interlocutor to talk to about your technical choices. You would also talk a lot about the product and strategy and reassure that the communications are effective and mutual knowledge updated.