jlevers

SEEKING WORK | Remote

I'm a full-stack developer and OSS maintainer, primarily focused on generating SDKs from OpenAPI specifications, building custom e-commerce integrations (Amazon, eBay, Shopify, etc), and modern PHP/Laravel development.

I've built dozens of one-off e-commerce integrations – everything from multi-platform inventory management systems to analytics dashboards to cross-border e-commerce tax compliance software.

I built and maintain the largest Selling Partner API SDK [0], which has 3.8M downloads and counting, alongside a number of other OSS e-commerce API tools [1], and custom tooling for generating SDKs from OpenAPI specifications.

I also have experience with several major web stacks (PHP/Laravel, Python/Django, JavaScript/Next, etc).

My email is jesse [at] jesseevers [dot] com.

[0] https://github.com/jlevers/selling-partner-api [1] https://github.com/highsidelabs

Much of my work the past few years has been working with Amazon's seller-side e-commerce APIs, and it's truly infuriating how impenetrable their "support" systems are. It's ridiculously hard to get even basic problems solved, and for some reason they make it near-impossible to get access to shipping and tax addresses via their APIs [0], which makes developing pretty basic functionality really difficult.

[0]: https://github.com/amzn/selling-partner-api-docs/discussions...

I rode through a huge area filled with these sorts of walls somewhere wayyy down a dirt road in rural central Mexico, sorta near Zacatecas. It looked like it was once a vineyard, or something like that...I'd never seen walls that looked this way before. Really beautiful. I had no idea that it was originally a European thing.

SEEKING WORK | REMOTE | NYC | [email protected]

Are you integrating with an ecommerce APIs and encountering lots of confusing behavior? Poor documentation? Really slow developer support? At Highside we have run into these issues many times before -- we learned the gotchas, so you don't have to.

We've integrated with Amazon's Selling Partner API (I wrote the top PHP library for it [0]), Walmart's Marketplace APIs, eBay's old Trading API and newer REST APIs, Shopify's REST and GraphQL offerings, and more.

As a two-person consulting shop, we are fast-moving, flexible, and can easily accommodate the inevitable scope changes that come with developing multi-marketplace solutions.

(While ecommerce APIs are our specialty, they're not all we do -- we have done everything from full-stack webapps to web3 projects to real-world lighting control systems.)

Get in touch with us at [email protected] or [email protected] (my personal email).

[0] https://packagist.org/packages/jlevers/selling-partner-api

NYC | Remote | [email protected] | highsidelabs.co

Are you integrating with an ecommerce APIs and encountering lots of confusing behavior? Poor documentation? Really slow developer support? At Highside we have run into these issues many times before -- we learned the gotchas, so you don't have to.

We've integrated with Amazon's Selling Partner API (I wrote the top PHP library for it [0]), Walmart's Marketplace APIs, eBay's old Trading API and newer REST APIs, Shopify's REST and GraphQL offerings, and more.

As a two-person shop, we are fast-moving, flexible, and can easily accommodate the inevitable scope changes that come with developing multi-marketplace solutions.

(While ecommerce APIs are our specialty, they're not all we do -- we have done everything from full-stack webapps to web3 projects to real-world lighting control systems.)

Get in touch with us at [email protected] or [email protected] (my personal email).

[0] https://packagist.org/packages/jlevers/selling-partner-api

disclaimer: i've only been doing this for a couple years...but it's gone pretty well. i've written this more like a story than direct advice, because i think all the twists and turns are relevant.

i went straight from college (dropout) into the consulting world right before COVID hit. i gave myself a year to get the consulting business going, and if that didn't work, i was planning to get a "real job."

i started off by leveraging my existing contacts in the software world: mostly a couple internships that I'd had (one before my year of college, one after). the first few months, i was only working for those two places while i tried to figure out how to expand. i started a blog [0] at this point -- it was mostly nontechnical content, but helped me demonstrate that i'm a sane person and a reasonably good communicator.

i started replying to the "Who wants to be hired?" threads here on HN and got my first couple (small) independent contracts there. then a family friend who runs a high-volume used book business needed his whole inventory/order management system redone from scratch, and i was a) cheaper and b) a known quantity, so he hired me. you can interpret this as me getting lucky, and in some sense it is, but i strongly believe that luck favors the prepared. i certainly wouldn't have gotten that gig if i hadn't been prepping for it, hard. this is when i started to raise my rates.

(you've probably seen this repeated endlessly on HN, but it bears repeating: raise your rates. raise your rates. and then raise them again. to match $XX/hr as a FTE, you need to charge at least 2*$XX/hr as a consultant. ideally a lot more.)

i spent tons of time reading HN and twitter, and responding to anyone who was doing something i found interesting. i went into these interactions with no expectation of getting work out of it -- i just wanted to meet people who were working on cool things. a few of those interactions did turn into work, and one person i met is now one of my best IRL friends. crazy.

at some point, i had to learn about a new amazon service (the Selling Partner API) for that bookstore project, and discovered just how badly documented and tested it was. after a couple months (!!) figuring out how to use it properly, i wrote a few blog posts about it, and people started hiring me from my blog (and now, my OSS SP API library [1]). between that, and a few of those people i talked about meeting via HN/twitter/etc, i've kept busy for the past 18 months. i actually just hired my first part-time employee, which is exciting :)

i think the three biggest things that have made me a modestly successful consultant are:

1. focusing on people over everything else. if you're a consultant, you're a salesperson, and in my experience just being genuinely interested in other people is the easiest and most effective form of sales. 2. writing online. it's cliched, but it works. you don't need that many people to see what you've written for it to be worth it -- i've never gotten more than 150 views in a day on my blog, and usually it's way less than that, but that's been enough to have plenty of work. 3. raising my prices ;)

i make a lot less money than i might by working for FAANG/etc, but i have total time and location freedom, i don't work a ton, and i really enjoy running my own show. ymmv, and good luck :)

[0] https://jesseevers.com [1] https://github.com/jlevers/selling-partner-api

thanks for the good wishes! definitely hit me up if you're in the area :)

That's so cool that you were part of the founding team for a makerspace! I'm working on building something makerspace-y right now...If you're open to it, I'd love to ask you a couple quick questions about it. If you're busy, no worries, I 100% get it :) my email is in my bio.

Well, it's not programming-related, but here goes...

I'm building a cooperative hands-on workspace in Brooklyn in an old warehouse. I have lots of interests that require space and tooling (old motorcycles/cars, woodworking, etc), and lots of friends in a similar boat (with fabrication, music, art, etc). I spent the last 6-8 months searching for a suitable space that I could actually afford, and finally found one about a month ago.

I'm in the process of gutting most of it (it's in gnarly condition) and rebuilding it to suit what I'm trying to do. If there's anyone here who lives in NYC, is good with their hands or wants to be, and is intrigued by the idea of getting a bunch of highly motivated and creative people together in one spot to build Cool Shit (whatever that may look like), feel free to get in touch.

My email is in my bio :)

I maintain a much, much smaller PHP library[0] (~1-2k downloads/month), and I've made a few thousand dollars in sponsorships, donations, and paid improvements to the library over the past year. I don't try all that hard to solicit donations, but I do have a donate button and a request for people to sponsor the library right near the top of the README. I noticed you don't have any visible donate button -- I'm guessing if you added one, and a little blurb about why people might want to donate, you'd up your donations quite a bit.

(Usual disclaimer, n=1, etc)

[0] https://github.com/jlevers/selling-partner-api

I built a PHP library[0] for Amazon's new Selling Partner API, because none of the existing libraries were feature-complete enough for the projects I was working on. To my surprise, it's actually picked up some steam -- ~400 installs (and lots of email/GitHub questions :) so far!

It's really fun having a tool that I created get some use.. I've benefitted a ton from the OSS community, so it's nice to be able to have that relationship go the other way, even in a small way. Plus, I've learned a lot about Swagger/OpenAPI, and the many quirks of Amazon's seller-facing software.

[0] https://github.com/jlevers/selling-partner-api

Silly question, but...is your megastick just a large-capacity USB stick?

Uranium can be extracted from seawater, and my understanding is that there's enough uranium in the oceans to last 10s (maybe 100s?) of thousands of years at current energy consumption levels. It's also renewable, albeit on a very long timescale -- but the timescales of consumption and renewal for uranium in seawater are much closer in length than the consumption/renewal timescales for fossil fuels.

I think that if you consider storage, then you can in fact amortize panel power generation across day and night, because you need more panels during the day to create the extra power that will be used at night (when none of the panels are actively generating power).

I don't think that what I said implies that, no.

Even outside of work, don't you find it satisfying to do something you're really good at? A dumb example: I love skiing, and the better I get at it, the more fun I have doing it. It's not because I enjoy showing up the people around me -- using my skills just becomes more enjoyable the better I get.

I agree that it's not necessarily true that everyone can become world-class at their job, but I think most people have the intellectual capability to become really good, if expending the necessary effort is worth it to them. In my opinion, a lot of being good at something is just being conscientious about it. Most of us will never be John Carmack, but there's a lot of space between "good" and "world-class."

It seems like maybe your goals in life don't line up with becoming "so good they can't ignore you?" I don't intend that as an insult in any way -- everyone has different priorities in life, and I don't know you, so it's also possible that you _are_ "so good they can't ignore you," and the book is incorrect.

Cal Newport has a book that discusses this this called So Good They Can't Ignore You, which I found really interesting. His thesis is basically that the people who are most satisfied with their work are those who stuck with something until they got really good at it, regardless of whether it was the topic they were "most passionate" about (passion can be fickle, IMO).

I fell for one of these offers on the first thing I made that got any traction -- it was a browser extension that solved an issue with a common photo hosting site, and I organically ended up with 25,000+ users, mostly on Chrome.

Eventually the photo hosting service itself solved the problem that my extension was solving, but pretty much everyone who'd installed the extension still had it installed.

At some point, a company offered to buy it from me for a couple thousand dollars -- I was 18, and it seemed like a miracle! They asked me to add some code to the extension, and I assumed their intentions were good. I added their code, which I now realize was some sort of tracking/advertising program...and my extension promptly got taken down by Google.

Quite the learning experience!

I'm currently working with this API, and I think that if I didn't have experience with Amazon's old seller API (MWS), I wouldn't even know where to start with this one. As it is, it's taken me many, many hours to figure out how to make this one (sorta) work.

(Shameless plug: I wrote detailed walkthroughs of how to get access to[0] and build a basic application with[1] the Selling Partner API).

[0] https://jesseevers.com/selling-partner-api-access/ [1] https://jesseevers.com/spapi-first-application/

For some reason the data you send to eBay's REST APIs doesn't always show up in their UI...specifically, if you use their RESTful Inventory API, you can't see _any_ of it from the Selling page! Not sure why...e-commerce APIs seem to be (on average) remarkably bad.

W.r.t. estimated taxes -- I seem to remember doing the math and concluding that I'd likely come out ahead financially by keeping the money for the estimated tax payments in the market, and then paying the late fees. Does that sound incorrect to you?

That's really interesting advice about avoiding granular time reporting, which I've been doing habitually. Your reasoning makes a lot of sense, and I think I'm going to move away from doing that.

As far as only breaking time down to half days -- I tried billing daily for a while, but it has felt clunky to me because I tend to work a ton some days and comparatively little others. Do you work at a relatively constant rate? If not, how do you decide when to bill a half day vs an hour?