Getting into an accelerator or incubator (even if it's one that's not popular) can really help with the legal stuff since you'll be able to get more advice and they will always have those boilerplate docs for you.
Form a C corp in Delaware and get the ownership figured out ASAP. I also generally think that all of the founders should vest (no cliffs or anything, but a four year vest for everyone will keep the company safe in the event one of you leave, even the CEO).
I agree with cglee's comment that you don't need capital right now, get more traction and build more product. Then in six months revisit the topic and determine if your organic growth is enough to sustain further growth or whether you'll need capital injection.
Raising money, btw, isn't always just about the money - if you pick your investors correctly they can help you and your business tremendously.
Agree with the above - altho forming a Delaware C Corp at this early stage is not necessary. It's become much easier now to form an LLC in your state of residence and convert at a later stage (if at all) to Delaware C if you end up raising money.
Thank you- somewhere it became lore that filing in Delaware is a necessary step to running a successful business. Most businesses that are cited as examples didn't start in Delaware, but did so after they had much to lose and on the advice of their highly-paid counsels.
If you have $1k in revenue, congrats, that's a great accomplishment, but with all due respect, nobody is going to file suit against a group of college students with $1k in cash.
The advice to just get an LLC going first then convert to a C corp is fine for their stage, I won't argue against it. However, what you're saying in opposition to forming a C corp early doesn't feel very rigorous.
From my limited experience as a founder, forming a C corp early has made some things easier. The time we had to convert a California C corp to a Delaware C corp became messy and I imagine converting a {whatever state} LLC to a Delaware C corp also has the potential for being messy.
The conversion cost us a lot of money to have done right when instead taking boilerplate docs and simply forming in Delaware first would have been much easier.
Angels and incubators will generally want you to be a C corp first or convert ASAP, too (which is a valid option but I feel like there are other more important things to be spending cycles and money on). Raising money without worrying about converting your corporate structure is a pretty big reason to just do it as a C corp from the start.
If you're going to file in Delaware, do so for a good reason. Just assuming you're better off having your legal entity setup there because anecdotally everyone says you should is no better than randomly picking what kind of corporate structure you'll use. What led you to transfer from California to Delaware?
Delaware is chosen by large corporations because it tends to be very business-friendly in the way its laws are written. However many other states are business-friendly too, and charge much lower filing and renewal fees.
What my advice boils down to is: talk to a respected small business attorney in your state and find out what your options are and what advice they offer.
Worry about the lawyers and corp and tax stuff later, when you have some success behind you. Put together a clear written agreement among founders, but don't throw money at the lawyers until you have the money to throw.
It's glossed over because it requires more than a single party to represent the "story" in a fair light and it would unprofessional for her to write about her biased emotional experience.
I think she is 100% in the clear for glossing over it and I personally would have left out bits like "backstabbing" &c... They may or may not have but describing her personal emotional experience while leaving out the hairy and sticky co-founder dynamics is a great way to share an experience of the "dark underbelly" [that is startups].
I experienced a co-founder split not too long ago and I can definitely tell you from my personal introspection that you may need to look deeper than "it was my fault for not seeing the warning signs".
It always takes two to tango and you're right to not bitch about them but then saying you were stabbed in the back is silly. Being a founder is tough, having co-founder problems is tougher, clearly understanding what your part in the dynamic is or was is even more difficult.
Sometimes, too, to get this level of internal depth takes distance from the people and the experience. It took about six to eight months for me to figure out what was rightfully my fault and what was rightfully my co-founder's fault - beyond "seeing the warning signs early".
Also, I don't know what your captable looked like but if you were the controlling interest you cannot and should not expect anyone to care about what position you're left in - you must be prepared to shoulder the burden on your own for a bit if they decide it isn't worth their time anymore. The more you own it the more you own it.
Hope you're okay and sorry if this comes off as admonishment, it actually comes from a heartfelt place. You're welcome to contact me personally if you want more support.
[EDIT]
Re-reading my comment, I might be coming off too much as an armchair psychologist, I'll leave the comment up for posterity and maybe you'll find something useful in it or not. Either way I think you've handled yourself well and hope that you yourself are doing well.
1. Even though I'd already spent 2 years on the startup, the first co-founder I bought on had the same equity as me. He wanted it, and I wanted someone fully committed.
2. I was off fundraising for 2 months, and my mistake was not communicating that really well with them. I wasn't a great leader at that time. However, I did notice something was off but I just thought it was post-yc depression (which is actually a thing, apparently). I asked them outright if everything was ok, and they said sure, that it would all be fine when we got back to Australia and moved on. I trusted them, and they lied to my face.
3. I think they were very naive, not malicious, in how they left. They thought everything would be fine if they just left, but thats not how startups work.
4. One of them refused to talk to me or give me an explanation after he left. I had to practically force him to meet me for some closure. Its like getting a divorce with no explanation.
I made mistakes too so its not all on them, but at the end of the day a co-founder is supposed to be your partner through thick and thin, and they bailed without talking through the issues at all which equates to stabbing me in the back. And they made sure to tell me this after I'd reimbursed them for thousands of dollars in expenses for their YC adventure.
The purpose of this is NOT to discredit them. I'm not a huge fan of them, but they dont deserve to be villified. I'm just trying to be a bit more transparent about what happened so that its helpful to some readers. I'm sure they've learned from the experience and will treat their next cofounders differently if they do start something else.
In progress on a startup now, and I have realized the most important thing is trust between the cofounders. There is a lot of people who want to be 'cofounders' but don't understand what it means, the real consequences and also what real company control means.
I also think YC might not be helping here - since being a YC founder is such a cachet resume item, the value of growing a company is discounted. This results in real problems as you have illustrated.
In the end, if you don't trust and know your cofounder as well as your SO, it's going to make the hard things that much harder.
I was in the same situation. In my case the reason why the co-founders left wasn't told was because the reason was that they thought their partner was too naive and incompetent to work with. Not something so easy to say straight to the face. In hindsight, I think there was no wrong in feeling betrayed in my case, but at the same time the co-founders did no wrong either. We were too inexperienced to handle the situation gracefully. Break-ups can't be amicable all the time. Everyone has their side of story.
The point went over your head, in any failed dynamic there are always mistakes made on both sides. I'm trying to encourage her to think deeper (not write) about it beyond not catching the "warning signs" which places her in a victim position. Whether she was or not, victim cycles create repeat patterns until the person sees their own role in it.
I'm encouraging psychological healing. I've very much been through a very similar experience.
[EDIT]
It actually sounds like it turned out well since she did end up with a solid co-founder relationship anyway. I'm leaving this up for posterity but now think my thoughts on this are unwarranted.
It's funny, strong type systems are really about explicit documentation. I'm sure the comments are good but translating a spec into Haskell types is a form of strong and explicit documentation that is also functional.
"Raise your rates" is excellent advice and, OP, you may or may not understand that it's actually more about psychology.
Higher rates help filter out demanding clients and also make it "worth it" when you do get a demanding one. Higher rates helps focus you, with 20 cheap clients you'll feel like going bonkers. With one or two high-paying clients you'll feel focused.
With higher rates and therefore more focus you also provide better customer service during the day. That will help reduce the amount of off-hour communications (this is also a boundary thing that Patrick already mentioned, be firm). Clients that understand that they get what they pay for and are comfortable paying a higher rate usually let you do what they are paying you to do and only communicate on the set meetings over minutiae.
My rate for each of my team members is 200+ per hour depending on what package they purchase (more hours = slightly lower rate, less hours, higher rate). We target corporate clients. Just it's been going so fast and been so stressful, it's not about the money. We've gone from 2 founders to 10+ employees very quickly.
And keep in mind, you'll want to be giving your employees a pay raise as well. They'll know what the clients are paying. Not a 1-to-1 increase, but maybe 30%. Make sure they realize you value their work.
$300 isn't unreasonable, there is a small dev shop in town with a proprietary CMS that charges $315 for creative/development work; and they're one of the most successful around town.
Once you've learned Haskell, actually, you can be far more productive in it than most other languages. The only piece of your statement that I'll agree with is that Haskell doesn't really have any great numerical or scientific tooling (like Python).
As languages go, Haskell out paces (not just in elegance but pragmatism too) most of the mainstream imperative languages.
The tooling for scientific computing does need to catch up though.
Can the typechecker ensure that your matrices (constructed from files) have compatible dimensions to be multiplied together? No? None of the compilers I've tried are much good for numeric computing. Since the error-prone parts of writing your code are not made easier by the typechecker, a dynamic language works just as well and has much lower cognitive overhead.
Remember that scientists don't care about the quality of their code. In many cases, once the code is complete, it will only run once and then be thrown away. There is no maintenance. Things like technical debt don't exist.
And pragmatism? Haskell doesn't even have loops. Loops with mutable variables inside are a very intuitive way of thinking about things and often a better fit to a problem than recursion. Sure, you can use tail recursion (which is just ugly looping) instead, but you're adding unwanted cognitive overhead.
What I would like is a functional language with enclosed, sealed off loops. Syntactic sugar for tail recursion, basically, but Haskell isn't built with programmers in mind; it's built for CS researchers. Computer language researchers, more specifically.
> Can the typechecker ensure that your matrices have compatible dimensions to be multiplied together? No?
Yes. In fact this is one of the earliest examples [0] of what you can do with the ever more numerous extensions to Haskell's type system.
There are BLAS bindings [1] and several native linear-algebra libraries in Hackage [2] that enlist the type-checker to enforce shape constraints at compile time.
> Remember that scientists don't care about the quality of their code. In many cases, once the code is complete, it will only run once and then be thrown away. There is no maintenance. Things like technical debt don't exist.
The code is usually used once, but it’s modified and “improved” for the next paper. So you add a few new routines here and a few files to read or write there, ... And one day you have a 95 pages fortran 77 program (it’s does’t even follow the fortran 90 standard).
I can do it in C# for small matrices, by including the dimensions as type bindings (http://bling.codeplex.com), but that is not practical for larger matrices, nor would it work for matrices loaded from IO.
Actually Haskell does have some dependently typed features (and is being extended constantly). The reason it isn't used in that particular package is a mystery, except that a lot of these things are very new and Haskell is an evoloving ecosystem. That particular package simply may not have a release that uses all the latest GHC features.
Repa for instance does provide type errors based on dimensionality of matrices. This is a package on Hackage.
Dimensionality is easy, its the lengths of these dimensions that are hard. E.g. you can multiply n by k, k by m matrices to get an n by m matrix, but anything else is a type error. In Bling, I had Matrix<LN,LK> * Matrix<LK,LM> => Matrix<LN,LM>, where LN,LK,LM are type parameters up to around 10 (L0, L1, ..., L10, enough to do 3D graphics, mostly, but wouldn't work for HPC where lengths are much longer and diverse).
Looking at the linked page, extent isn't a part of a matrix's type signature, so it would be checked dynamically, correct?
Haskell has a very neat interface for this, in that you build a special type which remembers the dimensions of a matrix as you build them, and then return either the result or a failure.
It's very simple to build a function which doesn't have to understand the possible dimension conflicts and lift it to work on this new type, returning an either (or a maybe, if there's only one failure mode) in place of a definite value.
It's also very simple to propagate such errors forward, so they'll short circuit a computation when you have non-matching matrices used in a calculation that's multiple steps.
In Haskell, I don't have to remember to write special functions which guard against this: I write functions that operate on the matrices and add the guarding at the very end. I can ensure that all my calls use the guarding functions, because they have a different type signature.
Trying to do this same thing in Python require that I remember to always use the guarded calls, and doesn't have as clean of an interface to create the guarded functions from standard functions.
What does it matter? No type-system will magically know ahead of time what the contents of the file will be before you run the program, but it can force you to do the appropriate checks when you do read it from the file.
I believe you could enforce something like compatible dimensions in Haskell in a library, but I could be wrong. If not, I wonder if you could do it in idris.
> Once you've learned Haskell, actually, you can be far more productive in it than most other languages.
Not when you're doing mathematical research. You can write x86 machine code and the time spent programming is still completely dwarfed by the time spent doing math. Mathematics is full of renowned professors who write F77 by hunting and pecking with one finger. There's no reason for them to use anything "more productive" because they can already code far, far faster than they can think of what to code.
There are extreme outliers for whom this doesn't hold, but they are few and far between.
Once you've learned Haskell, actually, you can be far more productive in it than most other languages.
Productive in what sense and at what cost (in time, especially, but generally)? What benefit is there to learning Haskell when the existing "tooling" in FORTRAN77, C, or C++ is quite adequate for the purpose of research? I mean for the specific purpose of applying it in a research context; not the general sense (i.e. this isn't meant to question the worth learning something new in general).
I've been a mathematician programming in a variety of languages over the last 20 years, and I can say that if it "doesn't really have any great numerical or scientific tooling" then I won't even give it thought number one for doing computations.
And you know, that's totally fair. I'm not a mathematician so my perspective is limited only to producing production software. I'm simply relating my own experience in the hope that people will stop judging Haskell as a "research language" with little to no industrial value.
That's the funny thing about researchers, some seem extremely obstinate (I suppose in many ways that's a required attribute otherwise they might give up). I wonder if this is why we still have Fortran code around...
Look, asking people to cite opinions is a dumb way of having casual discussion.
If you need any more input from me to convince you to learn something new, then it's not worth my time or yours.
Like I said the tooling isn't as mature but the language enables me to produce results faster with fewer bugs that is much easier to maintain down the road.
The only numerical computing I've ever really programmed for was manipulation of time series data and some standard statistical methods.
I did it at first in Python with Pandas and numpy. Then moved to Haskell. The language was better but the tooling I had to shore up in places.
Which bodes extremely well for them. They may quickly become the PayPal of bitcoin for providing a solid service allowing businesses to interface with BTC; as PayPal did for giving businesses and individuals a solid service to transact using the internet.
You can do "kind of" dependent types in Haskell too but it's an ugly mess (like trying to do it in Scala). Idris handles it really well for general programming tasks.
To each his own. I rarely hear fluent Haskellers say they don't care for the syntax though; if you haven't really gotten far enough to write production code in Haskell that leverages Haskell's powerful abstraction features, then you should and you might find the syntax growing on you.
The syntax is nice because it enables the programmer to express software in a terse way, generally favoring the types as documentation and a strong mental model to understand the abstraction.
Well, that project, Q just doesn't even share the same thesis of Haxl. At all. Two completely different projects, Q couldn't be used for what Haxl is intended.
If you had posted the link asking for a comparison, that would've been different, but your ignorance seemed obvious to me because of the haughty wink at the end of your posted link implying we were being let in on some kind of secret.
Form a C corp in Delaware and get the ownership figured out ASAP. I also generally think that all of the founders should vest (no cliffs or anything, but a four year vest for everyone will keep the company safe in the event one of you leave, even the CEO).
I agree with cglee's comment that you don't need capital right now, get more traction and build more product. Then in six months revisit the topic and determine if your organic growth is enough to sustain further growth or whether you'll need capital injection.
Raising money, btw, isn't always just about the money - if you pick your investors correctly they can help you and your business tremendously.