How Can I Reduce my Stripe Processing Fees? Pt. 1

by Tyler Newkirk on Oct 10, 2016.
_________________

If your business is like Gun.io, you do a lot of charging clients for services. Waiting for checks in the mail is so 2005, so you probably accept credit cards, and maybe even ACH. There are tons of blog posts comparing different payment services, like Paypal vs. Stripe, etc. We’ll leave that topic alone and say we chose Stripe. Assuming you did, too, our VP of Operations, Tyler Newkirk picked up the trail to determine...

How can I reduce my Stripe processing fees?

I was recently re-introduced to the idea of leveraging Stripe’s volume discount for our business by a savvy client of ours (check out AdvicePay, a FinTech company founded by Alan Moore and Michael Kitces). This wasn’t the first time I’d heard about Stripe’s willingness to work with larger clients, but I had yet to take the time to dive in and explore the potential benefits for which we might be eligible. Due to recent growth and a commitment to a lean operating structure, I deemed it time to give Stripe a ring.

Only I couldn't, because Stripe doesn’t list a public phone number for their sales or support teams. Bummer - be prepared for a semi-lengthy email discourse.

Before contacting Stripe’s sales team however, I spent a few hours digging online to see if I could solve any of these inquiries. Unfortunately I was unable to discover much more than a few vague pointers here and there. As a result, I wanted to record my findings and provide a resource for anyone else looking to understand Stripe’s volume discount.

I wanted Stripe to answer the following questions:

1. What criteria does Stripe use to determine volume discount eligibility?

2. Within that criteria, what level of volume is required for Stripe's discount?

3. How is Stripe's volume discount applied in practice?

In this three-part series I will explore these questions and the answers I was able to uncover.


Part 1

What criteria does Stripe use to determine volume discount eligibility?

Searching for the appropriate contact information, I found a sales contact form at https://stripe.com/contact/sales.  Encouraged by the fact that this form seemed specifically geared toward volume discount requests, I entered the required details and sent the form on its way, hoping for the best.

Within 24 hours I had an initial response, courtesy of a helpful Sam from Sales. Right off the bat he disclosed that Stripe typically only considers volume discounts for accounts “consistently” doing over $80,000 USD in transactions per month - with the caveat that account eligibility may still vary due to different characteristics unique to each business. He clarified:

Our pricing is largely driven by our underlying costs for processing your transactions which, as you can imagine, varies quite a bit from user to user. These costs are highly contingent on the business itself and the customer profile. Having lots of American Express, international and corporate customers will cause the rate to skew higher; having mainly domestic debit cards will keep the rate low.

Of note: Stripe actually publishes a figure much lower than Sam’s stated $80K on their own pricing page, as section that seems to appear sporadically based on some kind of split-testing:

Image4.png

I captured this image from their site on 9/22/16, so the exchange rate at the time of writing this article puts €30,000 at roughly $33,500. At no time even in the past 5 years has the exchange rate been anywhere close to convert €30K to $80K. Misleading, to say the least.  

With respect to Sam’s reply, although still somewhat opaque, I considered his admission a valuable one. In reading the remainder of his email though, I became increasingly confused as I realized Sam’s implication that our monthly transaction volume fell short of the $80,000 threshold. Confident that our business “consistently" exceeded this threshold (by a lot), I went to back into our Stripe account to investigate and gather concise numbers before responding.

Looking at our Stripe dashboard, I double-checked our figures. I played with the dates, creating a list of monthly transaction volume totals for the entire YTD.

Image1.png

I wrote back Sam from Sales, detailing our monthly figures for the past few quarters as well as some growth statistics to bolster the argument for our volume discount approval (and to learn how flexible Stripe might be with respect to other compelling statistics outside of the $80K/mo requirement). Feeling confident in my rebuttal, I anxiously awaited Sam’s response.

Arriving only 3 hours later, Sam courteously replied with his own (albeit significantly lower) monthly transaction figures, stating that based on his findings, we weren’t yet achieving the $80,000 monthly transaction volume floor to be considered for the volume discount. Frustrated, I read on - until I caught a phrase that Sam had used to describe his monthly totals (my emphasis added):

Please note that according to your recent net processing, it doesn't appear that Gun.io is exceeding the $80k / month minimum threshold for a potential pricing review of your account.

How does Stripe calculate “Net Processing”?

You saw it coming, and there it was - the crux of the issue. It now seemed obvious that we were referencing different equations to arrive at our monthly totals, yet I wasn’t sure where this ‘Net Processing’ total resided. A bit embarrassed by my ignorance and apparent unpreparedness for this discussion with Sam, I went back online to search for the source of his ‘Net Processing’ numbers before responding once more.

After minimal hunting, I learned that Stripe prepares a downloadable financial report for each user, housed at https://dashboard.stripe.com/account/data. The ‘Download Report…’ button will create and download a .csv file of your account’s history for your eternal viewing pleasure.

Image2.png

Looking at the report in Excel, I began to play with the different categories of numbers to work backwards into the monthly ‘Net Processing’ totals that Sam provided in his last email (annoyingly, there is no ’Net Processing’ label anywhere in the report).  It took a bit of guess-and-check, but I eventually realized that his numbers were the result of taking strictly 'Gross Amount' of 'Sales' (which I believe to be purely sales via CC's) and adding the negative 'Gross Amount' from 'Refunds' (if applicable). Eureka! See some example figures below:

Image3.png

The undimmed area provides the general reference of where to view the relevant information; the red boxes delineate the exact rows to sum for each month in order to find the ‘Net Processing’ amount. Per the sample image, the Net Processing Total equation for August ('8/1/16’ in cell D1) goes like this: $170,000 (Gross Amount, Sales) plus -$8,000 (Gross Amount, Refunds) equals $162,000 ('Net Processing Total').

To explain further - if Stripe were to consider this report for the volume discount, it would determine that August realized $162,000 in transaction volume; $21,500 in July; $86,500 in June. Despite the two months above their stated $80K threshold, I’d suspect that the variability in this example would be too great to approve a volume discount. Armed with new comprehension, I now understood how Sam (and thus, Stripe) calculated the monthly transaction volume (i.e. ’Net Processing’) numbers for our business.

Additional side note: the transaction amount detailed within your dashboard is the sum of both card and ACH transactions, gross of any refunds. For the sake of reducing your fee exposure you need to net out ACH like we did above.

tl;dr

Question 1: What criteria does Stripe use to determine volume discount eligibility?

Answer: Monthly ‘Net Processing’ totals, calculated by the sum of 'Gross Amount of Sales’ and ‘Gross Amount of Refunds’.

In Part 2 I’ll share what I learned about the actual volume of sales necessary to get Stripe to bite on a volume discount for credit card processing fees.




Building Serverless Microservices with Zappa and Flask

by Rich Jones on Mar 29, 2016.
_________________

Today, I'm going to show you how to write and deploy serverless microservices using Flask and Zappa. If you're new to Flask, you'll see just how easy is. However, if you prefer Pyramid, Bottle, or even Django, you're in luck, because Zappa works with any WSGI-compatible framework!

Zappa is super, super easy.

With serverless deployments, the web application only exists during the span of a single HTTP request. The benefit of this is that there's no configuration required, no server maintenance, no need for load balancers, and no cost of keeping a server online 24/7. Plus, it's incredibly easy and fun!

This demonstration will start with the most trivial example, and build to an example of a nearly-useful image thumbnailing service. In the next part, we'll look at setting up our service on a domain with an free SSL certificate using Let's Encrypt.

The Simplest Example

Before you begin, make sure you have a valid AWS account, your AWS credentials file is properly installed.

Flask makes it super easy to write simple web services and APIs, and Zappa makes it trivially easy to deploy them in a serverless way to AWS Lambda and AWS API Gateway. The simplest example even fits in a single .gif!

First, you'll need to set up your "virtual environment" and install Flask and Zappa into it, like so:

$ virtualenv env
$ source env/bin/activate
$ pip install flask zappa

Now, we're ready to make our application. Open a file called my_app.py and write this into it:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def index():
    return "Hello, world!", 200

# We only need this for local development.
if __name__ == '__main__':
    app.run()

The code is basically self-explanatory. We make a Flask object, use the 'route' decorator functions to define our paths, and call a 'run' function when we run it locally (which you can confirm by calling python app.py and visiting localhost:5000 in your browser.)

Okay, so now let's deploy! Open a new file called zappa_settings.json where we'll load in our Zappa configuration.

{
    "dev": {
        "s3_bucket": "your_s3_bucket",
        "app_function": "my_app.app"
    }
}

This defines an environment called 'dev' (later, you may want to add 'staging' and 'production' environments as well), defines the name of the S3 bucket we'll be deploying to, and points Zappa to a WSGI-compatible function, in this case, our Flask app object.

Now, we're ready to deploy. It's as simple as:

$ zappa deploy dev

And our serverless microservice is alive! How cool is that?!

Adding File Uploads

Okay, now let's make our application a bit more interesting by turning it into a thumbnailing service. We'll take an uploaded image, cut a thumbnail, and host the thumbnail on S3.

First, we'll need to add a few more packages from pip:

$ pip install boto3 Pillow

You used to have to manually compile PIL/Pillow if you wanted to use it on AWS Lambda, but since Zappa automatically uses Lambda-compatible packages via lambda-packages, we don't have to worry about.

Then, we'll update our code to add new imports:

import base64
import boto3
import calendar
import io

from datetime import datetime, timedelta
from flask import Flask, request, render_template
from PIL import Image

s3 = boto3.resource('s3')
BUCKET_NAME = 'your_public_s3_bucket'

and a new route:

@app.route('/upload', methods=['GET', 'POST'])
def upload_file():
    if request.method == 'POST':
        new_file_b64 = request.form['b64file']
        if new_file_b64:

            # Decode the image
            new_file = base64.b64decode(new_file_b64)

            # Crop the Image
            img = Image.open(io.BytesIO(new_file))
            img.thumbnail((200, 200))

            # Tag this filename with an expiry time
            future = datetime.utcnow() + timedelta(days=10)
            timestamp = str(calendar.timegm(future.timetuple()))
            filename = "thumb.%s.jpg" % timestamp

            # Send the Bytes to S3
            img_bytes = io.BytesIO()
            img.save(img_bytes, format='JPEG')
            s3_object = s3.Object(BUCKET_NAME, filename)
            resp = s3_object.put(
                Body=img_bytes.getvalue(),
                ContentType='image/jpeg'
                )

            if resp['ResponseMetadata']['HTTPStatusCode'] == 200:

                # Make the result public
                object_acl = s3_object.Acl()
                response = object_acl.put(
                    ACL='public-read')

                # And return the URL
                object_url = "https://{0}.s3.amazonaws.com/{1}".format(
                    BUCKET_NAME,
                    filename)
                return object_url, 200
            else:
                return "Something went wrong :(", 400

    return render_template('upload.html')

You'll notice that we're also using "render_template" now, so download this template as a file called 'upload.html' in a 'templates' directory within your project.

The other thing to notice here is that we're base64 encoding our binary data on the client, then decoding it server-side. AWS API Gateway can't yet handle binary data through the Gateway, so we have to encode it for now. Quite frankly, you probably don't want your data to go through API Gateway anyway, and you should just upload directly to S3 and then pass the key name to your service, but both ways work and it's easy enough to get our data for this example.

Finally, you'll also notice that we're appending an 'expiry' time into the filename of our thumbnail. Because our service is completely serverless, we don't use a database. So, we'll have to use other ways of storing information. If this service was part of a larger microservice deployment, we probably wouldn't worry about this here, but since we're still standing alone, we have to use what resources we have available to us for storing little bits of data that we might want. So, filenames and 'Tags' on S3 objects are super useful to us!

Now, you just have to update your code:

$ zappa update dev

And you've got a serverless thumbnailing service! Hooray! Browse to https://{{your_apigw_path}}/dev/upload to try it out!

Wrapping Up

So, now we've seen how trivially easy it is to build serverless microservices with Flask and Zappa. This combo is great for image processing services, text-processing, number-crunching, or even hosting fairly complex web applications if that's your goal.

In the next guide, we'll learn how to deploy our microservice to a subdomain with a free SSL certificate using Let'sEncrypt. Stay tuned!



Announcing Zappa - Serverless Python Web Applications

by Rich Jones on Feb 8, 2016.
_________________

Today, I'm pleased to announce the first major release of Zappa - a system for running "serverless" Python web applications using AWS Lambda and AWS API Gateway. Zappa handles all of the configuration and deployment automatically - now, you can deploy an infinitely scalable application to the cloud with a single command - all for a minute fraction of the cost of a traditional web server.

You can see at the core library on Github here, or the first major client library, django-zappa, here. I have also produced a screencast here if you want to follow along while trying it out.

Serverless?

I've used the word "serverless" to describe Zappa - but what does that actually mean? Obviously, it's not completely serverless - there still is a machine returning the HTTP response to the client.

The difference is that the server's entire lifespan exists within the lifecycle of a given HTTP request. Where normal web servers like Apache and Nginx have to sit idle 24/7, waiting for new requests to come in, with Zappa, the server is created after the HTTP request comes in through API Gateway. It then turns the API Gateway request into normal Python WSGI, processes the request, and returns it back through the API Gateway to the client. And then, poof - the server is gone.

Advantages

Scalability

This comes with some major advantages over traditional web servers. The first is scalability. Because AWS Lambda handles all of the requests, you can have as many responses processed in parallel as you need. With AWS Lambda, you get 100 function executions per second right out of the box, but the limit is arbitrary and if you scale beyond that you only need to ask Amazon to raise your limit.

Cost

The next major advantage is cost. With AWS Lambda, you pay by the millisecond. So rather than paying to have a beefy EC2 machine running 24/7 for your website, you only pay based on the amount of requests you server - which typically means you'll only be paying pennies per month for an ordinary website. Not to mention the cost saving on not having to spend time on deployment, operations and maintenance!

Maintainability and Ease of Use

Zappa is also incredibly easy to deploy. It's literally a single command - python manage.py deploy production - to configure and deploy your code, and after that, you never have to worry about it again. No provisioning machines, no setting up web servers, no DevOps, no operating systems, no security upgrades, no patching, no downtime. It just works!

Hacks

AWS Lambda and API Gateway are very new technologies, so there are a quite a few hacks that make this all possible. Those include, but aren't limited to:

  • - Using VTL to map body, headers, method, params and query strings into JSON, and then turning that into valid WSGI.
  • - Attaching response codes to response bodies, Base64 encoding the whole thing, using that as a regex to route the response code, decoding the body in VTL, and mapping the response body to that.
  • - Packing and Base58 encoding multiple cookies into a single cookie because we can only map one of a kind.
  • - Turning cookie-setting 301/302 responses into 200 responses with HTML redirects, because we have no way to set headers on redirects.

If you want to learn more, take a look under the hood!

Future Work

Though Zappa is now feature-complete enough for an initial release, there is still a fair amount of work to do. For instance, there is only one client library so far, django-zappa, but it should be fairly easy to add support for Flask, Pylons, and any other WSGI python web framework. The same principles that make Zappa possible should also work for NodeJS applications, but I find it's much more comfortable to develop in Python.

Try it out!

So give it a shot! It'll seriously change the way you think about deploying web applications. (If you just want to see a page served by Zappa, check out this little hello-world page with a self-signed certificate - real website coming soon!)

The easiest way to get started using Zappa is either going to be to read the Django Zappa documentation or to watch the introductory screencast.

If you're interested in contributing, you can also check out the code from GitHub and start submitting pull requests!

Enjoy!



Putting Down the Tools

by Marcus Blankenship on May 30, 2015.
_________________

Putting Down the Tools, Avoiding the #1 Mistake All New Software Company Owners Make in a Crisis

Yes, we’ve all done it.

I’ve done it. My previous managers have done it. And most likely, it’s the default setting for many battle-worn team leads.

In those crisis moments when expectations are high, everything is going off the rails, and the deadline was yesterday, all new tech agency owners will utter one fateful sentence.

It would be so much faster if I just did this myself.

Then they pick up the IDE, close the office door, and retreat into the code.

What they don’t realize is that they’ve just kicked off a chain reaction of negative work practices that will plague their team for months.

Save Yourself


As you probably understand all too well, the programming world is full of fires to extinguish. No matter what your company’s size or specialty, you are going to hit many, many pressure cooker days.

It’s up to you to anticipate the inevitable before it happens and make a firm, conscious choice not to try to code your way out of a crisis.

Why We Make This Classic Mistake


Making the switch from programmer to owner-manager can be flat-out awkward at times. You’ve gone from playing in the orchestra from leading it, which really shakes up your identity.

The most significant shift comes with the realization that you’re no longer a production unit, but you’re still working in an industry that values production. If you’ve always taken pride in the tidy transaction of being paid for your output, management is a strange new world.

Mixed Messages


First off, while having your name on the door is a much-coveted status symbol, deciding to run your own shop carries a built-in mixed message. It’s as if you’re telling yourself, ” I’m such a great programmer that I can go out on my own… and spend less time coding! Now doing less coding often feels like you’re doing less altogether or that you’re not contributing to the bottom line, especially when you’re just starting out.

Dependent on Others


Then there’s the new reality of how production happens. As a programmer, your brainpower and clever workarounds could conjure magnificent code from your fingers.

The programs you created could keep manufacturing production humming or bring it to a standstill. Entire businesses hung on your creations.

Now you’re dependent on other people to create the code that works this magic. And making the switch from creating your own technological incantations to supporting other people’s efforts really feels awkward for a while.

It Gets Worse


That clumsy beginner’s feeling gets cranked up when you face the new aspects of team dynamics and the reality of being without your most powerful weapon: your ability to code.

But you really get triggered by array of new expectations staring at you, like:

-Figuring out your clients’ agendas
-Assigning work to peers or former co-workers
-Dealing with morale speed bumps
-Steering through software quality problems–as the person who’s supposed to have all the answers

Adding a management role to the rest of your responsibilities can feel like stepping into a plane’s cockpit without any flight training. There are all these complicated, unfamiliar dials and gauges you don’t understand, and you don’t know if that blinking light means an engine has failed or the coffee’s ready.

In order to escape this anxiety loop, many business owners new to management fall into one of two patterns:

1. Code less, but indulge their coding desires by putting out fires and debugging whenever possible.
2. Code even more intently, blocking out team members and undermining their credibility as a leader.

Each of these positions is a pattern that will cause you to fail.

Let me say it again. Retreating to the position of “I’ll do it myself” isn’t going to save you any time or frustration. It’s only going to crank up the problems.

‘I’ll Do It Myself’: Say Hello to a Cascade of Problems


Once you’ve uttered those fateful words, you are no longer doing the job you were paid to do: leading. And if you’re not doing your job, especially when your employees need your leadership most, then no one is.

If you follow through on your natural desire to just do it yourself, you’ve chosen to avoid doing the following critical items:

Communication


Checking in with your team members and other principals is the heart of your work. But chaining yourself to your computer stops that cold. Suddenly, you’ve cut off any discussions about quality, progress, or individual development. Everyone loses.

Connection


Jumping in to correct someone else’s work not only short-circuits their learning process, it teaches them to do substandard work. Pretty soon they only turn in partially completed work because they figure you’ll just redo it anyway.

“Why bother?”, they think. They lose their drive, you lose their trust, and projects start to suffer.

It’s like a conductor wrestling the tuba away from the tuba player

Momentum


When you move back into production mode, there’s no one available to keep team moving forward. Essential work like status updates, work review, and new project preparation is completely out the window until you pick your head up.

You’ve just traded away hours of non-replaceable time and energy that should have been devoted to doing the job you’re hired to do. And when you get back to the work that’s been piling up on your desk, you’ve got to dig out all over again.

Sustainability


Let’s be honest. It feels great to be a hero, swooping in to save the day with a brilliant solution. But the cost is just too high.

A “quick fix” always takes much longer, turning your one-hour job into six hours (or more!) of panicked coding. While you code up a fix, your resentment and exhaustion build, and you’re teaching your team to depend on your last-minute efforts to bail them out instead of their own skills.

Management Skills


Running to your comfort zone feels safe, but it’s a very limited strategy that keeps you from making the changes necessary for you to be a good manager.

Trust me. Take a chance, drop the IDE security blanket and interact with your team instead.

Best Practices for Crises


While you’re waiting for your team to complete their work, you don’t need to sit passively or beat them with the boss stick. Here are a few tips that will keep you sane and your team on track.

Don’t Do it Yourself


If there’s a problem that you desperately need to rework, don’t do it yourself. Grab a programmer and say, “Let’s review this code together to fix it.”

Sure, you just scratched your itch by getting involved, but you’ve also established much-needed rapport and created up a teaching moment—for both of you.

Communicate


Panicked about a deadline? Get a status update from the programmers, adjust the workload if needed, and contact the client to give them an update.

Once again, you’ve opened lines of communication and placed your focus on the overall project, not just your team’s to-do list or your stress.

OK, Go Ahead And Code…


Can’t keep yourself away from temptation? Fine. Then code. But don’t code anything that will be used in production.

I cannot emphasize this enough. If you absolutely, positively can’t resist, then choose a project that is on the back burner. You don’t want to muck up a project in process.

This Is About the Long Game


Great management practices depend on a solid, thoughtful foundation created outside the heat of crisis. But it’s worth remembering that reputations are earned and character is uncovered during crucial, adrenaline-filled moments.

Remember that your purpose as an owner-manager is to create a team that is capable of producing excellent code.

In those instinct-driven moments, especially in beginner’s panic, please take a step back. Avoid this classic management blunder.



How to hire an iOS Developer

by David Tate on May 28, 2015.
_________________
You sat down to work today and see *Find an iOS Developer* staring back at you from the top of your todo list. This isn’t a straightforward task like “complete expense report”, “buy new coffee filters” or “fire Ralph” - this will take time, technique, and steady effort to complete.

First, the bad news: iOS developers are in high demand and have gone into hiding only coming out for interesting projects and to attend the WWDC. When you find a good one they can be very pricey.

But then the good news: Because of the obvious demand there are also thousands of people trying to join these group of talented recluses. But the challenge for you is to find members of the first group: experienced, talented, motivated and not the second group: inexperienced, looking to work on their first real project.

But first let’s talk about you.

Do you need an iOS Developer (yet)?

An iOS developer should be hired when you have a clear understanding of what you want and have decided that it should be for the Apple mobile market first (or in total / only). Do you know much about your target market - do any of them use Android? If so then hiring for iOS will not easily allow you to later support them; you might want to instead look into PhoneGap or equivalents.

Do you know exactly what you want?

Do you have an idea or a plan? You are competing for developers and one of the signals you send to people who listen to your offer is how well thought-out your project idea is. Did you just dream up something that you think would be cool or have you proven that there is a market for the product and know exactly how it will work? Do you have mockups yet of what it should look like? With tools like Proto.io and Invision you need no development experience yourself to create something that looks (and acts like an app on your phone!) to validate the user interface.

A solid iOS developer will entertain multiple project offers and you want to stand out as professional, hard-working, and with a fleshed-out plan. Your project should feel that it already has momentum and its success is an inevitability.

Let’s talk about candidates again.

Vetting Candidates

Let’s assume that you post to one of the millions of free-for-all job posting boards that serve as the new age classified ads. Your inbox is then full of developers awkward cover letters and details of their experience with technologies you have never heard of.

How can you tell if you are:
- Talking to someone with experience?
- Talking to someone that can actually complete your project?
- Someone that can communicate clearly with you in regards to the details of the user interface, project status, and any problems faced during the build?
- Talking to a real person and not a dog trained by a talented prankster?

Research online presence

Developers have a number of tools with which they can show general competence in technical and non-technical areas. Look into each candidate's online activity:
- Blog
- Github or other shared code
- Twitter profile

You don’t need to do any private investigation-style research here - you are looking to see if their blog or code contributions match the general tone of a professional, match with their declared level of experience, and don’t contain any odd red flags.

Look in more detail at code contributions

Open source is a great way to vet candidates - you can look at actual projects that they have built and use them to ask questions about challenges faced and areas for improvements. Open source contributions are a clear way to tell see who is active and hustling in the developer community. Watching popular projects is a good sign, committing to projects is a better one, and being the creator of projects that are used by others is the best tell that you are dealing with a good candidate.

Components Built and Used

Not all code can be shared though - working for big companies means that some developers are quite good but simply aren’t allowed to show it publicly.

This doesn’t mean you shouldn’t ask what they would pull off the shelf for a new iOS project. After giving them a few details about your project ask them where they would start at a technical level. What components would they use for authentication, logging, UI components, caching, network handling, testing, etc.?

Feel free to also ask about specific commonly-used libraries like AFNetworking, JSONModel, DateTools, etc. as well.

Complete Lifecycle Experience

An experienced iOS developer will have some pet apps that they have developed in the app store - either to make money or simply built when they were learning the platform. Ask them to showcase some of these and talk over the challenges they faced. Compared to all other development ecosystems the app one has the lowest barrier to entry: developers can directly make money from their work by only trading their time. What challenges did they face once the app was live?

Tool Opinions

A new developer loves everything about a tool, platform, or language while an experienced developer complains about its limitations. This is part of the experience lifecycle:
- You love it but feel like you don't fully "get it"
- You learn a good deal and start to realize the limitations of the new thing
- You master all the strengths of the tool, and start to feel the weaknesses
- You are challenged by the weaknesses and they frustrate you.
In that way very experienced people sometimes come across as hating the thing they use everyday while also quietly respecting it.

A good way to detect this phenomenon is to simply ask:
- What do you not like about Objective-C itself? How about Swift or Cocoa Touch?
- If given the chance how would you change the XCode interface?
- You are king for a day - how do you change the app review and feedback process?

Are They Constantly Learning?

Ask them about their first iOS project and things that they would do differently now versus in the past. Ask them what the last technical blog post, book, or talk they consumed that changed their knowledge was. What resources do they use to stay up to date with new tools, components, and techniques? How much do they know about WatchKit or HealthKit?

A Better Path

You could do all these things, roll the dice, and hope that your developer gets the project done or you could use Gun.io where your job posting will be seen by a multitude of iOS developers pre-screened and ready to work.



Learn and Earn!

Sign up for great tutorials, guides, rants, raves and opportunities to earn more money!