mikhaill

Agreed. I posted this comment a few years ago, but it looks like it's relevant as here as well:

A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.

The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.

They didn’t use a framework.

This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand that code instead of working on the revenue generating features.

We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.

It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.

This is exactly what I do at my SaaS platform. The "Welcome" email explains that you can do the click-here-and-do-yourself approach to onboarding or if you need help or have a question, just reply to the email. I think that's the lowest friction option for most new users. Over the few years that I had this in the welcome email, very few people took advantage of the offer and replied.

lbj, I agree. In my current SaaS app, I have a few customers that consistently try to take advantage of the billing grace behavior to save peanuts by canceling/re-subscribing/canceling/re-subscribing to try to fool billing system. Much as you, I've learned to let that go and hope for a change in behavior in the future.

To try to combat this issue in another app[1] I'm involved in the pricing packages are tiered at 5 SKUs / 200 SKU / Unlimited SKUs. As the customer grow, the driving function of plan upgrades is the volume of SKUs they work with. They also get extra features to better support operating at the higher volume. You don't get high volume features with the 5 SKU plan... We'll see how this approach shakes out.

[1] https://fnskustudio.com/pricing

A few years ago I attended a SaaS pricing discussion and two of the key insights that emerged were:

* For companies that gated based on usage, free/trial users were much more likely to make the transition to a paying customer. For companies that gated on features, free users tried to find all kind of ways to get things done without paying for the additional functionality.

* In the early days of many companies, most of the features of the product were given away for free, with just a a handful of features gated into premium plans. As companies grew, they realized that many of the features they should have gated, were now free, leaving little incentive for the users to convert.

Hopefully this helps someone.

Thanks for the sources, I'll have to check them out. We've recently spent a considerable amount of time tracking, analyzing and evolving our PagerDuty alerting[0], learnings of which we've shared in a blog post.

[0] https://goshippo.com/blog/evolution-our-pagerduty-playbook-f...

Shippo | San Francisco/SOMA | Onsite, Visa | Full-time http://www.goshippo.com

Shippo is a shipping API company that connects e-commerce businesses and marketplaces to multiple shipping carriers from one place. Our API powers shipping for companies like Shyp and Weebly, and we recently partnered with Stripe to offer shipping directly through their API.

With Shippo, businesses of all sizes can easily access Amazon-quality shipping operations and data. We are doing for shipping what Stripe has done for payments.

You will be faced with challenges in building and scaling mission-critical systems that are used by thousands of customers as a core part of their checkout flow and fulfillment process. From designing robust APIs to turning data sets into shipping recommendation engines, we need a strong and diverse team to help us grow quickly.

Current technical openings include:

* Senior backend engineers - we work with Python (Django), Postgres, AWS

* Senior frontend engineers - we use Ember

* DevOps (not listed yet)

* Support engineer

* Developer evangelist

* Senior product manager

* Content writer (not listed yet)

Technical hiring process:

1. Phone screen

2. Tech interview 1h via skype - pair programming

3. Onsite half day - pair programming/whiteboarding, meet the team/founders

If you're interested in any of these roles, please check out https://goshippo.com/jobs/ or email directly jobs [at] goshippo.com. Please be sure to mention you saw the note on HN.

When you’re a small business, it's important to establish repeatable methods that customers and your support team can follow easily. Do not over complicate. Find the single most efficient and scalable delivery method and perfect it. Start with email based support. Build your reputation as a dependable, knowledgeable and responsive machine through that single channel. You’ll later be able to expand to the other channels but not until you can afford it.

Depending on the size of your business I would suggest some tips from this blog post:

https://www.monsooncommerce.com/2015/11/customer-service-sof...

I don't have a story on startup failing due to tech debt, but I do have a story about technical debt forcing us to pass on potentially acquiring a startup.

A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.

The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.

They didn’t use a framework.

This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand the that code instead of working on the revenue generating features.

We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.

It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.

Just be careful about two things about the Nest protect, which are not obvious when you first purchase it.

1. If your house has the 3rd wire running between all the smoke alarms, so if one detects smoke, they all ring, Protect will not work with that system. It doesn't have the hook up for the 3rd wire. Nest will tell you to replace all the smoke detectors with the protect if you want the alarm to go off in the entire house.

2. If the Nest does detect smoke, it goes off and there is no way to turn it off until it thinks the smoke has cleared. Short of climbing up to the ceiling and ripping it off the power supply it will not turn off. You can't turn off the alarm via the app or by physically pressing the button.

I was originally very excited by the nest protect, but now not so much.

I would love to have a minute to talk to you about this.

I recently took over a new but quickly growing webstore. Just two weeks ago we decided that we want to add "Payments by Amazon" as an option for our customers. We run a Magento Enterprise platform, so I was certain there is an extension for this.

Welcome to the rabbit hole... Do I want Checkout by Amazon or Payments by Amazon? Not clear as advantages of either or why I'd go with one over the other. After spending a few hours reading the differences I gave up and called friends until I got a contact at Amazon payments. Spoke with a super nice rep who explained to me why I shouldn't bother with CBA and look at Payments API instead... "But, I see there is a CBA Magento extension," I protested, can't I drop that in and be on my way? Turns out the extension is maintained by a 3rd party, and as far as I could tell and the rep confirmed it isn't really maintained at all, so even if we spent the money on it, no one could guarantee that it will work.

Fine, let's talk about payments, if Amazon is pushing payments api for merchants, there must be something for Magento users. I get told sorry, maybe there is something in the works but if I want anything up and running for the holiday season, I have to roll my own, and by the way please sign up for another Amazon service (I accidentally signed up for CBA, because it wasn't clear which I service I needed).

So here we are… building our own implementation for Magento. I know it's not Amazon's problem to support how payments are used, but if you want e-commerce merchants to take you up on this offering, some love for the ecosystem will go a long way and some clarity that CBA isn't being promoted anymore.

But I have to give Amazon credit, I've spoken to reps over at Selling on Amazon, FBA, Payments and they are all sharp, knowledgeable and eager to help. I can't say a single bad word about the people that interact with your business customers.

You're the CTO of Amazon, the revenue you're going to get from my business isn't even going to justify a rounding error on the balance sheet, but if you want to hear from the merchants, I'm happy to give you a view from the trenches.

The issue is that when you use Facebook connect and get the user's email it returns the email originally used to sign up for facebook. Since people signed up years ago, many no longer have that as an active address, which leads to the poor email quality.

I'm working a community to helping startups find good help building out financial projections, revenue and cost drivers, market positioning, etc all things that are needed for raising funding. Building out models correctly can be a huge time suck for a startup without someone with financial background on the fouding team.

http://www.startupfinancials.com

I second qeorge's concerns about PCI compliance and credit card storage.

Futhermore, credit card processors and banks do not want to be on the hook for what happens when the items do not ship in these pre-order scenarios. The CCs are all about limiting their exposure to risk and this opens them up to a number of issues regarding products not shipped on time, not as advertised, etc.

SDL[1] maybe a bit overkill for what you need but we had good success with them for projects that required international translation.

[1] http://www.sdl.com

This is very interesting. As a runner myself I can see a lot of application here. Especially at the price tag of $15, and re-usable for different shoes its almost a no brainer to grab.

Now, if it could make me run faster....

Interestingly enough, one of the first YC companies from Summer '05, Memamp, tried to solve the Desktop search problem with replacing Finder.

I remember watching their demonstration during demo day and and being very impressed. Now the problem space is even harder, with cloud and hosted solutions in addition to all the desktop files.

I'll second @therealarmen point and agree with @sgdesign.

You priced the product based on real value and not perceived value, which represents how much customers feel a product is worth and is willing to pay for it.

If I have a web app, I sit and suffer as I look at my low conversion rate, low engagement and high amount of tickets coming to the support desk with annoyingly simple questions. All these items take up my time and effort, which cost money.

If your product means five less support e-mails, three more users that do not cancel because they understand how to use my app and ten more conversions a month, that right there is worth much more than $3 a month and I'd would be willing to pay for it.

FYI. It works in some localities. Many of the New York City McDonalds have delivery offered by the restaurant itself.

A small site I put together as a weekend project. For now limited to NYC (because that's where I'm) to figure out the right features and get some traction in one small area before opening up to other areas. The goal is to help runners find other people to run with who run the same distance/pace.

All feedback/suggestions are welcome.

Jason,

What's the rationale for bringing fulfillment inhouse? The economics and market trends seem to move the other way, in favor of drop shipping as much as possible. Catalog data problems? Financial? Branded customer experience? Partners can't ship properly? Just wondering...

Just to add one more point, the "offer" to keep the curtain was not done out of good will. The cost of them offering free shipping back to the consumer, re-stocking it, etc (do they even own their own inventory or is everything dropshipped?) would have been a lot higher then the value of the curtain.

Some of the e-commerce retailers who run their return numbers and know the cost of all processes will let people keep items they want to return because processing returns will end up more expensive for them.

Just as a note, I know that for e-commerce shopping cart forms, we specifically force users to enter their address information and zip code.

No matter what you think, users aren't paying attention to what they enter in the forms. Forcing them to enter their address and zipcode allows you to do a cross check to make sure they entered everything correctly.

You may find it annoying, but when it prevents people from ordering items to the wrong address, it's a pretty useful extra field.

Forgot to mention, there is a lot of pros/cons to 3rd party fulfillment and it has to be done right. If you seriously decide to look into 3PL warehouses, I'll be happy to give you more info about what you need to look at.

Certainly. None of these require 6 figure payments. There are some setup fees, (very reasonable) and then they usually charge per action (items packed, computers checked, etc).

Ones I worked with and would recommend: http://parcelport.net, http://amplifier.com/

Ones that I talked with but didn't have personal experience (yet)http://www.im-logistics.com, http://archway.com, http://www.capacityllc.com/

Each has their own pros and cons and it depends on what you're trying to accomplish.

Product fulfillment is hard but doesn't have to be a pain. There are plenty of very sophisticated 3PL warehouses that can do any type of fulfillment you need. At my last job I managed an e-commerce business and our process was so streamlined that we'd never actually touch our products. They were delivered from production directly to the 3PL fulfillment warehouses where the items were unpacked and stored. When the orders came in items were packed up, and shipped out, including international delivery. When items were sent out, we got the tracking numbers for the packages back so we could send customers e-mails (again all automated).

Some of the newer operations have staff on site that has electronics expertise and offer troubleshooting of arriving items, etc. It seems that having them flash NFC stickers shouldn't be soo bad to teach them (but maybe expensive).

The companies you mention are all fine shopping cart providers, but someone who's selling more then a few products (not even the size of Target) needs much more then a simple shopping cart.

* Integration into their inventory systems and multiple warehouses. Do you want to be able to buy on the site, pickup in store? That means you need to tie your ecommerce site to your brick and mortar systems.

* Do you have vendors that dropship on your behalf? You need a way to import their catalog data and send them their orders. Did they mess up and not have inventory by the time your order arrives, better have a way for them to notify you, so you can notify customers.

* Gift cards that work online and in stores.

* Customer service systems that tie to your e-commerce so staff can help customers.

* Syncing all sales data to your finance, ERP, business intelligence and other back-end systems.

* Returns? A system for RMA, tracking returns, issuing refunds and exchanges. Want to buy online/return to store? better tie your store systems to your e-commerce again.

* Marketing? Have to tie your online store your e-mail software.

Building a full fledged e-commerce solution is much harder than many realize. There are great tools that solve parts of what retailers need but there is no all-in-one tool to get a large retailer online and just working out of the box.

To follow up to the parent, there is a lot more to B-school then just to network. From common MBA-bashing that takes places on HN it seems that that many people fail to grasp the difference between building a product and building a company. If you want to build a product - MBA may not be necessary, but if you want to build a good company, an MBA will be a great help along the way. With all aspects of running a business covered in one class or another, you at least have an understanding of the issues you'll run into.

An MBA doesn't provide you a road map, it gives you a framework of how to approach business questions and an understanding how simple decisions cascade down to all aspects of a company (hr, accounting, operations).

You need to link your Google Analytics account to your Adwords account and all the information will flow automatically. After doing this, in your GA account under Traffic Source, the AdWords will populate with all your stats.

http://www.google.com/support/analytics/bin/answer.py?answer...

As far breaking down the Partner Sites performance, since that's usually the first thing I turn off... if I remember correctly GA will bunch all the sites under (content) word. Perhaps someone else here has a quick answer for you.

Here are a few tips that I always find useful for any AdWords campaign I setup.

* Select Google Search only

* Geo-target to US/Canada only (or add more countries if relevant)

* Enter negative keywords for the campaign that we know aren't buyers for the product (free, hack, crack, etc)

* Bid on Exact Terms and Broad Matches separately at different prices

* Track all keywords through analytics to see what the bounce rates and PV/Visit are to see if the traffic is bad or the site is failing to convert the visitors.

Google AdWords still work well for a number of campaigns I'm managing in different vertical industries. It does take time and effort to set them up right through, it's not as easy as just throwing in some keywords and waiting for cash to roll in.

Thanks so much for your help. I'll definitely check out the book. For others who may be looking, I found these excellent Xcode4 screencasts: http://pragmaticstudio.com/screencasts