Startup anti-pattern: ignorance

Listening to a startup pitch a few weeks ago I had to exercise effort not to shake my head in disbelief. The presenters were describing the products and business model of an established company I was very familiar with and doing it with what seemed to be blatant disregard of reality. They forgot to mention an entire product line that directly competed with their would-be product. They claimed the company had a different business model than the one it did. They misrepresented its scale, number of customers, etc. The obvious question was whether they were knowingly misrepresenting their competitor or whether they were confused or simply unaware. After the Q&A it became clear that they were just ignorant.

The event took place during a startup competition. What struck me was that, without exception, following any one startup’s presentation, at least one of the reviewers who was an expert in the startup’s space would point out some way in which the entrepreneur(s) had either forgotten to investigate something of critical importance to their business or deeply misunderstood it following a typically brief investigation. The startups were gearing to spend time & money based on flawed conclusions. They had all taken on significant risk because of their ignorance.

Note: links to undocumented anti-patterns will take you to the main list.

Startup Anti-Pattern: Ignorance

What it is

Ignorance is not knowing what you don’t know. It may be the most common startup anti-pattern. It should not be confused with making an explicit, considered decision to ignore something (knowing what you don’t know).

Ignorance is often found with arroganceescapism, not knowing your investors and unrealistic expectations. It is usually deadly when combined with a big dose of arrogance, perhaps as a result of the Dunning-Kruger effect (a cognitive bias).

Why it matters

Ignorance hurts startups in countless ways, of which the following are pretty common:

  • Ignorance creates an invisible bias in decision-making, which often results in significant time and resources being wasted.
  • Ignorance sends a very early negative signal that turns experienced talent away. Would be co-founders, executives, employees, investors, board members and advisors may determine it is not worth their time to engage, especially if they see ignorance co-occurring with anti-patterns such as arrogance and unrealistic expectations.
  • Ignorance is self-perpetuating: it attracts equally or more ignorant talent to the company.
  • When equally or more ignorant investors join an ignorant company, they can experience a very rapid & destructive “falling out of faith” when they have to come to grips with reality. I have seen several companies hit the wall at high speed because expected financings did not come together as planned for this exact reason.


Ignorance is easy to diagnose but it takes work. There are two main strategies.

The first strategy is introspective in nature. It involves comparing observed outcomes with clearly recorded expected outcomes and then analyzing the root cause of the difference. Ignorance creates an omitted variable bias (OVB) in decision making and will likely cause reality to not match expectations. If there is no obvious known root cause for the observed difference the likelihood of OVB increases and ignorance should be the suspect. The benefit of this approach is that anyone can practice it. The main problem with it is that it is a lagging indicator: it detects problems after they have already occurred, which is inefficient. The biggest reasons why this diagnostic cannot be applied are: (a) that expected outcomes are not clearly recorded or (b) that an incorrect root cause is identified (see the scapegoat anti-pattern).

The second strategy is a leading indicator. The idea is simple: seeks external feedback to diagnose and eliminate ignorance early, before it costs you. External feedback can come through materials or through people. In the latter case, the trick is to be humble and genuinely interested in people’s opinions or you may not get them or, worse, you may get an artificially positive opinion whose goal is to get you off their back. Another thing to watch out for when talking to experts is the mentor whiplash anti-pattern.

Arrogance and confirmation bias are the most common anti-patterns that make the diagnosis of ignorance difficult.


When exogenous forces such as luck and timing affect the success of a startup, ignorance is often confused with genius, vision, and perseverance. As the saying goes, sometimes people can do something just because they don’t know it couldn’t be done. Statistically-speaking, this is not a good strategy for startup success.

Refactored solutions

Once diagnosed, the refactoring of the anti-pattern very much depends on the nature of ignorance involved and its root cause.

Some methodologies can fix the symptoms by making it very difficult to remain ignorant. For example:

  • Agile development methodologies make it difficult to hide issues related to engineering execution.
  • Customer development makes it difficult to remain ignorant about issues related to product/market fit

Fixing the symptoms is not the same as identifying and fixing the root cause. If the root cause is simply lack of knowledge or mis-understanding it is relatively easy to fix. If the root cause is deeply character-related, e.g., a fundamental lack of curiosity or excessive narcissism, then the fix typically has to involve finding more suitable roles for the people involved or transitioning them out of the company.

Effective startup execution requires agile handling of uncertainty. Eliminating ignorance has a cost, which needs to be considered relative to its potential benefit. A particular form of the analysis paralysis anti-pattern involves spending far more time than it is worth attempting to diagnose and eliminate ignorance.

When it could help

As with most things, ignorance happens on a scale and there are many cases in a startup’s life when measured amounts of ignorance can have positive effects, at least temporarily:

  • Ignorance can facilitate focus by artificially simplifying planning & execution.
  • Ignorance can be motivational by creating artificial certainty and hiding potentially bad, demotivating news.
  • Ignorance can bring resources to the company, e.g., investment capital from investors who might be put off by reality.


The startup anti-pattern repository is work in progress helped immensely by the stories and experiences you share on this blog and in person. Subscribe to get updates and share this anti-pattern with others so that we can avoid more preventable startup failures.

Posted in Anti-pattern, startups | Tagged , , , , , | 5 Comments

One more vote for functional languages

I’ve been doing a lot of work on startup anti-patterns recently so it seems fitting that I look at other things through that lens.

Every few months I fall into the same debugging anti-pattern:

  1. I start using a debugger to track down a difficult-to-pin-down issue.
  2. I set up a watch expression to look at some complex data structure.
  3. The debugger evaluates the watch expression outside its intended scope, which (sometimes) creates a side effect that cannot be observed directly at the time it happens.
one_tricky_problem + one_semi_random_problem == frustration

Yesterday, it happened when I was debugging a VBA script that’s part of my automation of tax preparation. Don’t ask: it seemed like a good idea a long time ago and is probably the main reason I occasionally use my old Windows machine.

The VBA Dictionary class will auto-create elements for any key it doesn’t have a value for. Therefore, a watch expression such as:


can easily create a Nothing value with an Empty  key when myClass is in scope and when myKey is a Variant not in scope.

The previous time I experienced a similar problem was in Ruby when the watch expression had a side-effect on a cache whose logic I was trying to debug.

Eventually, I hope to develop a sixth sense for this debugging anti-pattern. In the meantime, I don’t like my options: (a) not use a debugger or (b) live with paranoia about watch expressions.

Alternatively, I could embrace functional programming languages without side effects. I wonder what their debuggers are like…

Posted in Code | Tagged , , , , , , | Leave a comment

Top startup anti-patterns

Following my post on the value of startup anti-patterns, with the help of readers of this blog and friends from the startup ecosystem, I put together a list of the more common ones that I encounter. The list used to be here but I moved it to a page on startup anti-patterns for easier linking and sharing.

Posted in startups | Tagged , , , | 7 Comments

The value of startup anti-patterns

The TechStars Boston spring startups are looking very promising. At the mentors dinner tonight I had conversations with several of the companies and a common question came up: “What makes startups succeed?” My usual answer to this question is along the lines of “strong teams, hussle, luck & timing.” While in my experience these are the things that actually, casually make startups successful, it’s not a very satisfying answer to the question because luck and timing are not in a startup’s control.

Driving home, I was thinking about this and about a better way to share what I’ve learned about startups over the years as an entrepreneur, angel investor and venture capitalist. I’ve been lucky to have had access to the inner workings of dozens of startups through their lifecycles, often from founding until exit (good or bad). Still, beyond “strong teams, hussle, luck & timing” I don’t know what makes startups succeed. Maybe I’m not as smart as the people who confidently talk about the patterns of behavior that make startups successful. Maybe I’m in too much agreement with Guy Kawasaki about why good strategies fail. Who knows?

I do, however, have a pretty good idea about what makes startups fail. There is much more data about startup failure, especially if, you could see not just the external spin and the post-rationalizations but real, unadulterated startup stories unfolding over time. So, while the Law of Large Numbers cannot help identify strategies for startup success, it can definitely help identify strategies for startup failure that are repeated over and over again.

An anti-pattern “is a pattern … that may be commonly used but is ineffective and/or counterproductive in practice.” Commonly observable strategies of startup failure are startup anti-patterns. This is the startup community’s form of collective insanity, using the definition that “insanity is repeating the same mistakes and expecting different results.” I think this has a lot to do with the bias of talking about what makes startups successful as opposed to what prevents startups from failing. For better or worse, it is only the startups that repeatedly don’t fail that have the chance to take advantage of luck & timing.

I don’t mean failing in the lean startup sense of always making new mistakes quickly & cheaply. The process of learning through small failures is similar to the process of walking through controlled falling or to getting a few bruises and bumps on the playground. It’s good stuff and there is plenty to laugh about at the end. No, when I say failing I am referring to a startup wasting significant time & resources, to walking becoming tripping, the controlled fall becoming uncontrolled, the trip to the playground ending up in the emergency room.

Over the next few months I will document some of the key startup anti-patterns I see frequently. I’d love to learn about your experience with them. Subscribing is the easiest way to ensure you get the updates.

Posted in FastIgnite, startups | Tagged , , , , , | 7 Comments

The fastest way to learn a new programming language

In school, I used to pick up new programming languages for fun. I could take my time to learn & explore them in whichever way felt right, without pressure. I implemented for fun and the code rarely ended up in production. By contrast, at work, I pick up a new language because something urgent & important is best done in it and, typically, the time between learning and production deployment is less than a month. Going through this several times over the past two years at Swoop (most recently with R) I think I’ve finally cracked the code on how I can help myself learn a new language in the fastest possible way.

I’ve lost count of how many programming languages I’ve written code in over the years (the most obscure one is probably ROBASIC). I think about programming using meta-patterns that transcend languages. When I encounter a new language, I go through the following phases:

  1. Curious George. During this phase, which usually lasts only a few hours and involves semi-random exploration of tutorials, reference manuals, blog posts and StackOverflow posts, I get my bearings straight, find analogies between the new language and ones I’m more familiar with and choose my initial tooling.
  2. Mario Bros. -> Super Mario Bros. In this phase, which usually lasts several days, I try to bring the meta-patterns I’m comfortable working with from familiar environments (the sewers of New York) to the new environment (the Mushroom Kingdom). It involves diving head first into advanced language features and building various utilities that I find lacking in the environment, e.g., debugging tools, all in the context of early prototypes of whatever it is that I need to work on.
  3. Bull in a china shop. This is the phase where my noble goal of bending the language to the way I solve problems meets the harsh reality of me being a neophyte in its intricacies. The observable attributes of this phase are lower velocity, increased use of expletives and more time on StackOverflow. The amount of time in this phase varies. The “Eureka!” moments are fun but overall it’s a dip in the experience curve.
  4. Singin’ in the Rain. With newly acquired knowledge and improved language-specific testing/debugging skills, the bull gently transforms into Fred Astaire. Coding is a lot of fun again. It’s time to go to production.
  5. Obi-Wan Kenobi. Over time, the interaction with the new language improves the meta-patterns I use for problem solving. I tend to use less and simpler code using natural language idioms as opposed to generalized utilities & abstractions. It’s like changing from using the Force to allowing the Force to do things through you. It takes a long time to get here. More often than not, I never do.

In trying to optimize the way I learn languages, I focused on the obvious problem: the bull in the china shop phase. My guess as to the root cause of the problem was simple: I didn’t know what I didn’t know and it did have a tendency to bite me. Here are some examples of the types of advanced language features that have helped me in a big way but not without some very frustrating moments along the way:

  • In C++ template meta-programming turned out to be awesomely useful and powerful but rich in undocumented cross-platform compiler bugs at a time when my company was shipping on four different OSes.
  • In Java it had to do with dynamic bytecode generation for decorators of untrusted third party code in the days before J2EE was mature.
  • In Python a logically simple approach to behavior injection ran into edge cases where stateful decorators didn’t mix well with inheritance. To boot, it crashed the debugger, which made it all the more fun to fix.
  • In Ruby metaprogramming for dynamic domain specific language definition my approach ran afoul of the behind-the-scenes trickery of ActiveModel::Callbacks. To prove that Ruby is just like Python in all ways that matter, this was another situation where the debugger crashed liberally.
  • In JavaScript inside MongoDB, all hell broke loose when we tried to do some seemingly trivial map-reduce work. Forget crashing the debugger (there is none): it crashed the whole database server.
  • In R, whose best and worst quality is that it is designed by statisticians, it was custom environment chaining.

In reflecting on this after my recent experience with R, I felt stuck between a rock and a hard place. If I use advanced language features to gain productivity I risk wasting time debugging bizarre edge cases. If I do not use the types of language features that make it easier to map how I think about problem solving to a particular language I lose productivity. The obvious approach was to look for a way to discover the unknown unknowns sooner but I didn’t have an easy way to do this without creating waste in the agile sense. Even test-driven development didn’t help much as the majority of the problems that cost me the most time reared their ugly head deep into implementation.

What I now think is an optimal approach to learning a new programming language–at least for me personally–required two serendipitous discoveries. The first came because of some work we are doing at Swoop with thoughtbot. I’ve often preached that it’s important to invest in learning the intricacies of whichever testing framework you use so that you are able to express the way you think about testing more naturally in code. I thought I knew how to do this reasonably well but seeing those guys work challenged me to think about testing abstractions in a new way. The second serendipitous discovery came as I was trying to extend the testthat R package with some new primitives for the types of tests I wanted to write. I ended up hitting several unknown unknowns in that process but, perhaps due to the natural way tests isolate state & dependencies, it happened early and in ways where a solution or a workaround was easy to discover.

With the help of serendipity and reading the code of several testing frameworks, I’ve come to the hypothesis that either reading and extending existing test frameworks or building new ones (perhaps as a tool to go along with early prototype work) is the best way for me to both efficiently learn the advanced features of a new programming language and to efficiently discover in practice the unknown unknowns that will likely bite me. I expect the same to be true for other experienced developers but I would not recommend this approach for developers who are not at ease with abstract & pattern-driven problem solving.

I’m going to test this hypothesis with Lua, which I started learning tonight because of some Redis scripting work we are exploring. Here is the result of my first hour with Lua. I’m not trying to re-create TDD frameworks such as telescope or busted. (In fact, I’ll probably transition to busted as it is the most RSpec-like thing in the Lua universe and I find contextual test writing to be far easier and more enjoyable than xUnit-style test writing.) This was simply the fastest way for me to dive into learning the language as opposed to using the language. This approach also yielded the first unknown unknown: the curious fact that the built-in mechanism for determining the length of a table (Lua type that doubles as a array and hash/dictionary) seems to only work for arrays (not hashes) without nil values. I’m sure every Lua programmer learns this sooner rather than later but I also found no mention of this in the handful of tutorials & blogs posts I explored during my Curious George phase or the section on tables in the definitive Programming in LuaI am left with the hope that this time around my bull in the china shop phase will be shorter.

Posted in Code, Swoop | Tagged , , , , , , , | 1 Comment

Startups and intellectual property: how much is a muse worth?

Startup founder agreements has been the top post on my blog for a long time. The post has become much more valuable due to the many interesting questions & situations described in the comments. Every now and then, a comment merits its own post:

I have a question regarding IP rights.
I came up with a concept for a new start-up and the main feature. That particular feature I came up with was during a chat to one of my start-up partners.
The question is whose idea is it and who owns an IP for it? I feel I came up with it, but it did not happen by itself, it was triggered by conversation.
I would like to be fair.

This situation comes up frequently in one of the following two forms:

  • A friend helps you come up an idea and start a company. She joins in with you. How much was her help worth? Does she own part of the idea or not?
  • Continuing from the previous example, after unsuccessfully trying to raise money, you decide to shut down the company. Who would own the idea after the company is shut down?

I call it The Muse Problem. In Greek mythology, the Muses were the goddesses of inspiration  in arts & science, catalysts of creativity and invention. If a muse helped a songwriter create a great song, how much of the song’s royalties should the muse get?

Is this and the question of how much of an idea a startup founder’s muse owns there are at least four separate ways of looking at the situation:

  • Letter of the law. There is a legal standard as to what constitutes full IP ownership. I will not pretend to fully understand it but the gist is that it requires non-trivial input for someone to co-own IP with you. Just being in the same room is not good enough. What about if the idea came from a conversation? What about many conversations? If the conversation(s) were specifically about IP/idea generation, I can tell you that in every single case I’ve approached a lawyer for advice the answer was, “it’s depends.” In every other case they’ve said, “no worries.”
  • Practice of the law. In theory, theory and practice are the same. In practice, they are not. Assume for a moment that you thought you owned 100% of the idea and that, given perfect information, the letter of the law would be that your friend co-owns the idea with you. She finds out about it and she gets really upset and she hires a badass lawyer and they come after you or, if the IP is now owned by your company, your company. What’s the worst that can happen assuming they can prove their case? If the idea has generated significant value, there could be some liability. How much would depend on how the case goes. If you’ve filed a patent on the idea without disclosing your (now former) friend as a co-inventor then the patent could be invalidated. In practice, however, there are so many ifs and buts along the way starting with the likelihood that your friend probably doesn’t think she owns a part of the idea, going to the fact that most ideas don’t generate enough value to justify lawsuits and ending with the observation that proving a case of wrongdoing may not be easy.
  • Industry practice. In industry practice, for better or worse, most high-tech founders do not share any portion of their IP with the muse or muses who do not join their startup. It’s just part of how high-tech operates. I don’t have great data about other fields.
  • Your practice. In your life, you have to decide what’s fair and how you will feel about your actions down the road. There is no right answer and, most likely, nobody will call you out if you do nothing.

The second case, when a company shuts down, is essentially equivalent. If company intellectual property is not a collateral someone can lay a claim to, it reverts to it owners prior to incorporation. If the intellectual property was created inside the company, e.g., when three employees file a patent, the IP goes to the inventors and is shared equally. The equal sharing I honestly find a little random but it’s very rare that the IP would be worth anything. If it were, someone would try to buy the company for the IP.

Back in 2008, I worked with a friend for many months to incubate a company and then, after the crash and after failing to acquire another company’s technology for what we thought was a fair price, we decided that it didn’t make sense to raise money. I had created a significant amount of intellectual property during that period. My friend was not technical and took no part in the actual IP creation but he was my muse and our conversations helped me think through things. I reached out to him and offered him a significant share of future IP proceeds. I did it for two reasons. First, it was the right & fair thing to do. Second, our agreement eliminated legal risk for any third parties interested in the IP down the road and, consequently, increased the value of the IP for me and my friend.

Here is the template for the agreement letter that we used:


As you know, I am now planning to go forward with trying to pursue protection for the PERPETUAL MOTION concept that we’ve discussed. I wanted to recognize your contribution and to confirm that it is my intention to have you share X% of proceeds from the sale or license of the patent I file on this concept.

I plan to seek patent protection on the high level concept that I presented to you originally. At this point I do not believe I need to have you execute any patent application. However, I would ask that you agree to cooperate in this regard (at my expense) in the event it becomes necessary.

I believe it is also the case that your prior contribution to the project was done on your own time and expense, and further that all information and ideas you have provided me were done outside of any employment or other obligations you might have or owe to any third party.

Please indicate your confirmation of these terms by signing this letter and returning it to me at your earliest convenience.

Caveat: I am not a lawyer and if you are in a situation like this, you may want to seek professional advice. This is not just CYA language, it’s what I’ve done more than once in the past.

The Muse Problem comes up in one other situation: when co-founders are wondering how to split up a cap table. In this case, however, the real question is not how much of the idea anyone owns but how much of the total capitalization of the company is the idea worth. Ideas without smart & hard-working people who can execute them and adapt them to new circumstances are not worth that much.

Posted in startups | Tagged , , , , , | 3 Comments

The Swoop Credo

I just updated the Swoop entry on my Linkedin profile with the following:

Swoop is a native advertising platform that puts users first.

  1. Web democracy is powered by advertising-supported content.
  2. Traditional online advertising makes the Web suck.
  3. Swoop can fix (2).
Posted in Advertising, Native Advertising, Swoop | Tagged , , , | Leave a comment

Raising money for revolutionary startup ideas

Between the work we do at Swoop and some big idea startups I’m advising, revolutionary innovation has been top of mind for me recently. That is why the following statement Richard Feynman makes in a lecture about the difficulty of understanding quantum mechanics stuck a deep chord:

So, it will be difficult but the difficulty really is psychological and exists in the perpetual torment that results from you saying to yourself “but how can it be like that” which really is a reflection of an uncontrolled–but I say utterly vain–desire to see it [quantum mechanics] in terms of some analogy with something familiar. I will not describe it in terms of an analogy with something familiar. I will simply describe it.
— Richard Feynman

Revolutionary innovation often faces substantially bigger challenges than evolutionary innovation not because of the magnitude of change it requires in a real sense but because of the magnitude of psychological change required to accept the possibility of a new reality before it has fully manifested itself.  Startups building revolutionary new products and services face the additional challenge of having to convince investors about the possibility of a new reality before they can set out to create it. The typical approach is to draw on analogies to existing solutions, to the current reality. Compare. Contrast. Educate. This sometimes works but, in my experience, it often confuses investors more than enlightens them. Explaining the future in terms of the past works well for small evolutionary steps but if often fails for big discontinuous leaps. What analogy can you draw between a sailboat and steam ship? Between a propeller and a paddlewheel? A hot air balloon and an airplane? A feature phone and the iPhone?

Rather than highlighting the potential of the future, analogies to the past constrain it. Worse, in the minds of investors, these comparisons can set up the wrong benchmarks to evaluate a startup’s progress by, which can hurt the company in later financings. Sometimes, the best strategy is to just tell it like it is and only engage deeply with investors who “get it”, who are willing to suspend their disbelief and imagine a world where the revolutionary innovation has reached critical scale.

Here is Feynman. The quote is at 7:10.

Posted in startups, Swoop, VC, Venture Capital | Tagged , , , | 14 Comments

Startup Weekend Rocks

Startup Weekend has become a real force for fostering entrepreneurship. I had the pleasure of speaking at the BostonEDU Startup Weekend kick-off yesterday. Some of the ideas were impressive and I do expect to see a couple of interesting companies come out of the event. I also met some really strong developers. If their startups don’t get off the ground, I hope they consider joining me at Swoop.

Here are my slides and the crib notes:

  1. Do not be cool. Entrepreneurship is about action. Most startup ideas never get acted upon. Let your emotions give you energy to overcome the inertia to act.
  2. Practice educated ignorance. To solve big problems in new ways you need to be reality-based but you also need distance & perspective. Find a balance and avoid what at TechStars we call mentor whiplash.
  3. Bring a gun to the knife fight. Startup Weekend may be about a lot of things–building community, collaborating, coming up with good ideas & starting companies to name a few–but at it’s core it is about selling. You need to sell yourself and your idea so that you can recruit a great team at the event and accomplish seemingly impossible things over a single weekend.
  4. Beware the Kool-Aid. Not the proverbial Kool-Aid, the banal one. Startup Weekend is an athletic event: 54 hours of excitement and stress. If you want to perform at your best, you have to take care of your body: eat well & stay hydrated.

If your startup gets off the ground, you may find the following helpful:

Posted in startups | Tagged , , , , , | Leave a comment

Solve hard problems and fly robots

Because we are in stealth mode, people regularly ask me what we do at Shopximity. Stuck between changing the topic and saying that we make shopping better for everyone, I decided to take a different tack and tell the cold, hard truth:

There it is. There is no more. For now. Except that we are looking for a someone special.

Front-end Engineer (UI/UX)

Shopximity, an early-stage startup, is looking for a front-end engineer. You’ll work with industry-leading Bocoup engineers and an experienced team of startup veterans at Shopximity to develop a system that will improve the user experience of 100 million people daily. As the first front-end engineer, you’ll both define and solve the many interesting problems we face as we develop the product from scratch.

In case you are not the right person but know someone who is, we offer a $10K referral bonus. Try us. Tell us about your worst competitor’s best engineers and we’ll hire them away and send you $10K.

Requirements and qualifications:

  • Thorough experience with JavaScript, HTML, and CSS (we use JQuery).
  • Thoughtful interaction design and sensitivity to user experience.
  • Experience working with high-traffic websites (>500k monthly uniques).
  • Entrepreneurial approach to your work. We don’t want to manage you, we want to enable you to make the product better and its users happier.

Things we’ll like about you:

  • You are a problem solver and you like gnarly problems.
  • You care deeply about user experience and empowering users.
  • You’ve worked at, or are very interested in, consumer web startups.
  • You’re always thinking about ways to make your favorite websites better.
  • You’re interested in the mobile web, too, and have some ideas about designing for smaller screens.
  • You’ve worked with a backend framework like Rails (which we use), Django, etc.
  • You’re not afraid to voice your opinion and argue for it, but want to arrive at the right decision after thoughtful debate about what’s right for the product and its users.

Things you’ll like about us:

  • You’ll work with, and learn from, people who have built many startups before, taken them public and won TechCrunch 50 awards. Think a startup bootcamp but faster paced.
  • We have a mission. It is to make shopping better for everyone on Web and mobile.
  • We use a cutting-edge stack in the cloud that will handle many billions of requests.
  • We’re well-funded and backed by some of the best investors from the East and West coasts. Well-known people in our industry have joined as advisors to help us in our mission.
  • We take care of our engineers. We have a bright office next to the Alewife T Station. Every workstation has two top-of-the-line monitors and an adjustable-height desk.
  • Generous compensation, including ground-floor stock options. We want to hire the best and treat them like the best.
  • We’re very early stage (5 people) and you can make a meaningful difference immediately because we run weekly sprints.

Please send your resume as well as links to your portfolio, GitHub or Dribbble. Include links to professional or community projects you’ve worked on. Additionally, please tell us a few sites whose UI/UX you admire, and tell us why.

Posted in Shopximity | Tagged , , , , , | 2 Comments