1. For Entrepreneurs building companies in the United States and India

    Cherian  ·  June 18, 2014


    Recently a former colleague asked me about setting up office in India and San Francisco. Compiling these tidbits made me realize how reusable this database is. A part of it is useful for any foreigner setting up shop in the Valley.

    Cucumbertown is a network for cooks. Think Tumblr for cooks. We are a platform with users from around 162 countries but we haven’t generated revenue yet. Our lead investors are from the Valley and by virtue of that we setup shop in the United States with a subsidiary company in India. Fortunately or not we don’t have to deal with payments in India.

    I have met quite a few entrepreneurs building SaaS products billed both in the US and in India. If that happens to be your case, reach out to a CPA in the US and a CA in India. This post is not going to help you much.

    Continue Reading →

  2. Redis on steroids: Autocomplete using Redis, Nginx and Lua

    Arun  ·  May 21, 2014

    Serving autocomplete instantaneously has always been top priority for us and till recently we hacked our way through by caching autocomplete entries on the client side (embarrassing, I know) and syncing from the backend. This helped us serve results at “Google Instant” level until the data began to hit memory limits (client side arrays sizes). Continue Reading →

  3. Our San Francisco brunch

    Cherian  ·  May 4, 2014

    The pics say it all (although we didn’t do justice with the photos) .

    With the cherry blossoms, Chinese lanterns, cheese spread and the most beautiful of people – this was our perfect Japanese autumn.

    If you would like to do a local Cucumbertown get-together, reach out to us. We’d be more than happy to help.

  4. Why we love the Vine way of recording

    Cherian  ·  January 14, 2014

    One of the major requests we have from our users is for a start/stop recording button as opposed to a press to record button like Vine.

    Here’s something I got last night

    “My sis was visiting and she took most of the video. But I really want to have the ability to take a video by myself with least amount of fuss. This translates to front view camera capability with touch-and-release ability to start/stop recording.”

    Continue Reading →

  5. The tools that define us. Building a tool culture

    Cherian  ·  January 11, 2014


    From time immemorial I’ve had a Swiss army knife in my pocket. My best friend introduced me to this during my engineering days and ever since this Swiss knife MiniChamp has gone on to be an integral part of my life. This Swiss army knife has gone on to fix laptops, fans, a mini surgery to remove coconut husk fiber from the toe to all the way from hitchhiking in Europe, the south East Asia and my daily routines. I had this tool in my pocket for over a decade and had to part this only once when I inadvertently took it to the airport check-in. To me this tool is like wearing a suit. It empowers.


    We humans are characterized for our ability to build and use tools to make us efficient. Its that one defining character that terms us “intelligent”. It’s that trait that separated us from the evolving family. We started using flints, stone, levers and sticks all the way to mixers, washing machines, cars, elevators and airplanes to make our lives better. For the vast majority of us we don’t know how life is so simple with the tools that make it implicit and invisibly defining.

    Build tools. Builds tools to replace yourself

    During my Zynga life when the company was scaling we were constantly pulling all-nighters to keep the games up and running while dealing with variable peak loads. It was evident to my director Manoj Sharma this wasn’t going to be sustainable. Programmers are going to just burn out, he knew. And one day he made statement that had a profound impact. “Build tools. Builds tools to replace yourself”. He probably meant it as a passing statement but the thought grew on me. I’ve always had a hacker mindset and all of us hackers try to maintain DRY. But when I combined this with a tool building mindset I realized we could build an incredibly good hacker culture.

    Till then it never struck me that tools should be built with a systematic, focussed  and scientific approach (focussed with an emphasis). We have .bashrc files that define us. SSHing to 100 machines is 5 keystrokes for us.

    But this is more about a systematic approach and company wide approach. Something that requires a mindset change top down.

    At Cucumbertown, we push ourselves to builds tools to make this proactive.
    Tools that start with a simple alert mechanics like :

    1. Informing admins about weird ingredients
    2. _CT__New_Ingredients_-_cherian_in_gmail_com_-_Gmail

    3. Informing the team about deployments that go to production
    4. Deployment_complete_on_prod_-_cherian_in_gmail_com_-_Gmail

    5. Building toolkits on top of Jenkins to automate everything
    6. Hipchat_example_jpeg-5

    7. Referrer spike – an email alert tool that lets us know if we got slashdotted
    8. __prod_cucumbertown_com___Referer_Scan_report_at_Sun_Aug_11_01_01_02_2013_-_cherian_in_gmail_com_-_Gmail_jpg

    9. Search log tools that let us know of invalid search results
    10. Pasted_Image_1_11_14__2_08_PM-2

    11. Engineering is right now in the process of building a tool to create a stage subdomain whenever a new branch is pushed from git with a new DB and settings. Delete all the env and domain when the branch is deleted. From a git post commit hook.
    12. Cucumbertown-10

    Most of these are tools are part of every company/startup in some manifestation.
    Building a tool culture isn’t easy. Especially when you are a startup.

    1. A tool is mostly useful when its 100% complete. Most of us tend to take it to the 80% level. At this level its not good enough for “others” to use.
    2. Tools are laborious to build. The time required to build a tool might not seem to be worth the end result. At least initially.
    3. The time that we all fight for.
    4. The most important is focus. If this is not directed to the solutions we need at that stage of the company, it’s easy to get distracted. For startups time is the most precious currency.

    But despite the obstacles, building a tools culture has more benefits than you can possibly think!

    1. A tool culture immediately differentiates the hackers from the rest.
    2. Tools bring tremendous attachment to the product/team. The gratification of achievements in efficiency is beyond words.
    3. Tools set the stage for code reuse. Consequently for open sourcing them. If the stage is set right at the onset, a lot of the problems of encapsulation and project management become implicit.
    4. Opens source tools are the best evangelists. Think firebug.
    5. Tools help ramp up new hires. They contribute to it and the eco systems matures.
    6. A tool culture makes the company sexy. Dashboards, pagers, scripts.
    7. There is an element of serendipity. Phabricator, Urchin Analytics etc. ended up being companies.

    To do this much like a company HR policy, tool building has to be integrated into the engineering manifesto.

    1. Tool building should be part of an employee’s Objectives and Key Responsibilities.
    2. Direct focus to ensure this aligns with the company’s strategy at that stage.
    3. Mechanics should be built to measure a tool’s efficiency but not at the cost of company productivity.
    4. Above all the founders have to believe.

    I’ve realized that tools not only make us efficient but the incredible sense of gratification the author gets by improving an otherwise manual process is unparalleled. The same way I feel watching a Maker video.

    Do you think its justified building a culture like this in early stages? What more can I do to get this into the DNA?

    What are some awesome indispensable tools you have built?
    Oh and btw, yesterday I fixed my teamie’s MacBook pro keyboard with the Swiss knife

  6. When to propose a relationship… to your anonymous visitor

    Ankit Jain  ·  January 8, 2014

    Tl;dr: This article is a to-do guide on choosing a appropriate delay in showing sign-up overlays to maximize conversion

    Cucumbertown is centered on concept of users showcasing their culinary skills to world. We have everyone from home cooks to food bloggers to chefs sharing their personal experiences. All this content is available for anonymous viewing, i.e. without requiring to sign-up. Think Quora, but without restrictions. Our challenge is to convert anonymous visitors to registered users and get them engaged with the platform. Again, think Quora.

    Always Be Closing (Alec Baldwin as 'Blake' in 'Glengarry Glen Ross'; - 1992)

    Always Be Closing (Alec Baldwin as ‘Blake’ in ‘Glengarry Glen Ross’; – 1992)

    Continue Reading →

  7. Choosing the perfect Typeface – Cucumbertown’s journey

    Anand  ·  October 24, 2013

    Update: Cucumbertown is in midst of a design overhaul. We are now focusing on mobile and web and the design changes are not yet reflected on the site. Subscribe, if you want to keep yourself updated. The journey is exciting and we are chronicling everything.

    Typographic conscience hit the web design world quite some time ago. Oliver Reichenstein passionately wrote about it in his controversial– Web is 95% typography post. Yet, unlike the other design choices that are data driven or research oriented, type choices we designers make tend to be ad-hoc and impulsive even today (I have experienced everything from blind folded choices to democratic voting).

    Continue Reading →

  8. Python metaclass registry pattern

    Arun  ·  September 5, 2013

    In some cases we would like to tag certain classes or get a list of classes that inherit from a common class. An example of this is the django admin classes. To get a list of admin classes django uses admin.site.register function.

    The problem with this pattern is you need to call a function to register your classes.
    What if we could avoid that?

    Using python meta class, we can do the same thing in a super cool way.

    Straight to the code:

    class MetaRegister(type):
        REGISTRY = {}
        def __new__(cls, name, bases, attrs):
            """ @param name: Name of the class
                @param bases: Base classes (tuple)
                @param attrs: Attributes defined for the class 
            new_cls = type.__new__(cls, name, bases, attrs)
            cls.REGISTRY[name] = new_cls
            return new_cls
    class BaseClass(object):
        __metaclass__ =  MetaRegister
    class MyClass(BaseClass):pass
    class YourClass(BaseClass): pass
    print MetaRegister.REGISTRY
    {'MyClass': <class '__main__.MyClass'>, 'BaseClass': <class '__main__.BaseClass'>, 'YourClass': <class '__main__.YourClass'>}

    In verbose mode:

    Suppose we need to get a list of classes that inherit from BaseClass, we need to define a new metaclass for it, and override the __new__ magic method. Whenever python needs to construct a new class inheriting our base class, python looks if the __metaclass__ attribute is set, and uses it to construct the class calling the __new__ magic method on your meta class. “type” is the base class for all class objects.

    You can also do some filtering/processing in your metaclass based on the name, other bases or attributes to get a refined registry.

    That’s it!